added Slackware build script
[k8jam.git] / CHANGES
blob91ec9e84182e109ec2c724d99907d4db06af5b28
1 Changes between FT-Jam 2.5.2 and 2.5.1:\r
2 =======================================\r
3 \r
4 I. Engine Improvement:\r
5 \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
9 \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
15   generate the binary\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
24 I. Building Jam:\r
25 ----------------\r
27  On Unix, FTJam can now be built with the traditionnal mantra, that is:\r
29    ./configure --prefix=<yourprefix>\r
30    make\r
31    make install\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
35  the INSTALL file.\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
51  instead of:\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
82   ISO C89 construct:\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
96   dependency graph.\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
102   defined in Unix.\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
132 chapter).\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
148      INTELC       Intel C/C++\r
149      WATCOM       Watcom C/C++\r
150      MINGW        MinGW (gcc)\r
151      LCC          Win32-LCC\r
152      DIGITALMARS  Digital Mars C/C++\r
153      PELLESC      Pelles C\r
155 the same table for OS/2 is:\r
157      WATCOM      Watcom C/C++\r
158      EMX         EMX (gcc)\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
204 release.\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