1 Changes between FT-Jam 2.5.2 and 2.5.1:
\r
2 =======================================
\r
4 I. Engine Improvement:
\r
6 Integration of Kai Backman's fix to dependency computations. When an
\r
7 included file is newer than the file including it, the later must also
\r
8 be part of the list of 'updated' actions.
\r
11 II. Installation fixes:
\r
13 On Unix, building Jam will not longer complain that 'bin.unix' was
\r
14 skipped. This generally needed to 'make' or 'jam' invokation to properly
\r
17 Also, the binary is now automatically stripped on Unix systems
\r
19 'jam package' now works correctly to generate package files on Unix
\r
21 Changes between FT-Jam 2.5.1 and Jam 2.5:
\r
22 =========================================
\r
27 On Unix, FTJam can now be built with the traditionnal mantra, that is:
\r
29 ./configure --prefix=<yourprefix>
\r
33 some simple Makefiles are also provided for a small number of selected
\r
34 platforms (mainly Windows and OS/2). For more information, please read
\r
38 II. Command line processing:
\r
39 ----------------------------
\r
41 command line options can now be placed anywhere. In classic Jam, they
\r
42 must always appear before the target names.
\r
44 additionnally, if a command line argument includes, but doesn't start with
\r
45 a '=', it it treated as an implicit '-s' option (variable definition).
\r
47 this means that you can write things like:
\r
49 jam install DEFINES=DEBUG
\r
53 jam -sDEFINES=DEBUG install
\r
58 III. Engine improvements:
\r
59 -----------------------
\r
61 III.1. The JAMCMDARGS:
\r
63 A new builting variable has been defined. When FT-Jam start, it defines
\r
64 the variable JAMCMDARGS which contains the list of targets used on the
\r
65 command line when Jam was invoked.
\r
67 This is useful to provide richer control flow in the Jambase depending
\r
68 on command line arguments.
\r
71 III.1. Expansion Modifiers:
\r
73 A new modifier 'Q' has been added in order to quote the result of
\r
74 an expansion. This basically replaces \ by \\ in expansions.
\r
76 this is mainly useful within Actions block to prevent shells from
\r
77 doing stupid things to your parameters when they contain a back-slash.
\r
79 III.2. HdrMacro built-in rule:
\r
81 Jam's automatic header inclusion scanner now supports the current
\r
84 #include MY_HEADER_H
\r
86 to do this, you need to use the new HdrMacro built-in, and give it
\r
87 the name of one or more header files containing the definition of
\r
88 MY_HEADER_H. This will only record those definitions that look like
\r
89 valid header inclusion paths, like:
\r
91 #define MY_HEADER_H <mypath/myheader.h>
\r
92 #define MY_HEADER_H "myheader.h"
\r
94 These macro definitions are recorded by Jam, and used later during
\r
95 the header scanning process to add the corresponding file(s) to the
\r
98 III.3. Variable import:
\r
100 When Jam starts, it begins by importing all variables from the environment.
\r
101 Classic Jam had a bug that made it crash when very long variables where
\r
104 Additionnaly, variables whose content begins with "()" are ignored since
\r
105 they correspond to function variables in Unix shells like BASH, and don't
\r
106 have any meaning in the context of Jam
\r
108 III.4. mkjambase now supports DOS text files:
\r
110 the 'mkjambase' file didn't support DOS text files well. It created
\r
111 a corrupted image of the Jambase within the Jam executable.
\r
114 III.5. Library scanning bug fix:
\r
116 Jam couldn't see object files with long file names within library files
\r
117 on Windows when they were generated with Mingw. This caused the
\r
118 corresponding object files to always be re-built.
\r
120 IV. Jambase improvements:
\r
121 -------------------------
\r
123 IV.1. Compiler selection through the JAM_TOOLSET:
\r
124 -------------------------------------------------
\r
126 on Windows and OS/2 only, FTJam selects the compiler like Classic Jam
\r
127 by exploring the environment, looking for specific variables.
\r
129 However, it none is found, it looks for the JAM_TOOLSET variable and
\r
130 use it to select the toolset being used. This list is displayed by Jam
\r
131 when JAM_TOOLSET is undefined or set to an unsupported value (see next
\r
134 Nothing is changed on Unix and other platforms.
\r
137 IV.2. Improved compiler support:
\r
138 ---------------------------------
\r
140 FTJam supports a lot more compiler than Classic Jam. Here's a table
\r
141 that maps values of JAM_TOOLSET to the corresponding compiler on Windows:
\r
143 JAM_TOOLSET Toolset Description
\r
145 BORLANDC Borland C++
\r
146 VISUALC Microsoft Visual C++
\r
147 VISUALC16 Microsoft Visual C++ 16 bit
\r
149 WATCOM Watcom C/C++
\r
152 DIGITALMARS Digital Mars C/C++
\r
155 the same table for OS/2 is:
\r
157 WATCOM Watcom C/C++
\r
160 Nothing is changed for other paltforms. on Unix, including Cygwin, selection
\r
161 is performed through the CC environment variable, which defaults to 'cc'.
\r
163 IMPORTANT: if you're using a Unix emulation layer like Cygwin or MSys, you
\r
164 should use a version of FTJam specially compiled for them, which will act
\r
165 exactly like the Unix version.
\r
168 IV.3. Support for building and linking shared libraries & DLLs:
\r
169 ----------------------------------------------------------------
\r
171 Some new rules have been defined to be able to build and link with
\r
172 shared libraries (on Unix) and DLLs (on Windows only). NOTE THAT THIS
\r
173 SUPPORT IS STILL EXPERIMENTAL AT THE MOMENT. These rules are:
\r
175 SharedLibrary library : sources : import : def ;
\r
177 Compiles 'sources' and generates a shared 'library' (i.e. DLL on Windows,
\r
178 or shared object on Unix). Calls SharedObjects and
\r
179 SharedLibraryFromObjects
\r
181 If SharedLibrary is invoked with no suffix on 'library', then
\r
182 $(SUFLIBSHR) suffix is used (.so on Unix, .dll on Windows)
\r
184 'import' is the name of the corresponding import library for Windows
\r
185 and OS/2 platforms (ignored otherwise). If it is not defined, it will
\r
186 default to 'library' with the $(SUFLIB) suffix.
\r
188 'def' is the name of the corresponding definition file used to generate
\r
189 the library on Windows and OS/2 (ignored otherwise).
\r
192 SharedLibraryFromObjects library : objects : import : defs
\r
194 Equivalent to LibraryFromObjects for shared libraries and DLLs. See
\r
195 above for the description of parameters
\r
197 LinkSharedLibraries program : library ;
\r
199 Used to link a program to a shared library generated through
\r
200 'SharedLibrary'. Equivalent to 'LinkLibraries'.
\r
202 NOTICE THAT IT IS NOT CURRENTLY POSSIBLE TO BUILD BOTH A NORMAL AND
\r
203 A SHARED LIBRARY WITH THE SAME NAME. We'll try to fix this in a later
\r
207 IV.4. Experimental Package Management:
\r
208 ---------------------------------------
\r
210 The end of our Jambase contains the definitions of several new rules
\r
211 that can be used to define independent software packages and manage
\r
212 their installation, deinstallation and dependencies on various platforms.
\r
214 This code is highly experimental at the moment and we will not describe
\r
215 it here in detail. If you're interested, look at the end of the Jambase
\r
216 for rules whose name begin in Pkg (e.g. PkgBegin, PkgEnd, PkgUses, etc...)
\r