This page is devoted to an ongoing design discussion about the evolution of Boost.Build.|
* Boost.Build is currently in a fairly mature, stable state. It is being actively used for real projects other than Boost.
* Since its inception, new features have been added to the core Jam language in a version we're calling ``Boost Jam''. This version is available through the Boost CVS repository at tools/build/jam_src (currently on the jam_src branch, but that will change). The new features are documented at http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/boost/boost/tools/build/build_system.htm#core_extensions.
* Most of the new features were designed to allow Boost.Build to expand more gracefully and robustly than it has so far.
* A rewrite is planned, to take better advantage of the new features.
* Several people have expressed an interest in working on Boost.Build. Some have even contributed new features to the current system. If you are interested, please join the jamboost yahoogroup at http://www.yahoogroups.com/group/jamboost.
* Bootstrapping Jam
* Spaces in Path Names
Features in progress
These features have either not been completely integrated into the CVS source
base, or there is more work to do before they are complete.
Command File Support ===
Windows has a well-publicized problem with long command-lines: since Jam
executes all commands by writing .bat files and invoking them, command-line
length is subject to the limitations of .bat files. For most Windows linkers,
the problem can be solved by using a "command file" or "response file",
which lists the files to be linked. This functionality has been implemented for
MSVC, but still needs to be generalized.
Improved ALL_LOCATE_TARGET behavior
Vladimir Prus has contributed code which
makes it so that ALL_LOCATE_TARGET can be used to name a path relative to the
project root (rather than the invocation directory) where all built targets will
be generated. Eventually, we'd like this behavior:
* if BOOST_TARGET_ROOT is a relative path, built targets will end up in a subdirectory of the project to which they belong. This is just like what Vladimir did, except that I am accounting for multiple interdependent projects. So, if you invoke "jam -sBOOST_TARGET_ROOT=build", built products will end up in a subtree of each project root directory: <root>/build/...
* if BOOST_TARGET_ROOT is an absolute path, built targets end up in a subdirectory of $(BOOST_TARGET_ROOT) which has the same name as the project.
Markus Schöpflin has
contributed support for STLport with msvc6. See "msvc-stlport-tools.jam" in CVS.
Future versions of Boost.Build will generalize this so that it was not tied to a
Intel compiler support
Beman Dawes contributed Intel Win32 compiler
support. However, it used a rather crude cut-and-paste technique from the msvc
toolset definition instead of factoring out the functionality. There's also no
Linux support yet.
This section is devoted to issues that make me scratch my head. Discuss!
* Ease of installation/running. We'd all like to be able to simply unpack the build system and use it. See /Packaging.
* Distribution of prebuilt executables. How should this be done?
* Naming Conventions
* Generalizing Response File Support
* Should ``<find-library>xxx cause ``xxx.lib to appear on the link line under Windows?
** PROS: This will ease the authoring of cross plattform jam files as link.exe does nothing to append .lib itself.
** CONS: Windows developers are used to specify xxx.lib and not xxx.
* Invoking Toolsets Through Scripts
:: It is often best to invoke toolsets through some kind of script. For example, see como-tools.jam (currently only set up for Windows). The windows toolset requires several separate lines of set-up before actually invoking the compiler. Jens reports that he has several Comeau installations on his Linux system, each one invoked through a differently-named script. He should be able to use the same toolset definition file as we use on Windows.
The goals may be realized by developing this proposal.
Currently, toolsets files are being re-included often as a project Jamfile is
being interpreted. Building in the status subproject (which defines many
targets) is currently slow, but not mostly because of the re-inclusion: it's because
the ``flags'' rule uses split-path on all of the features. Anyway, I'd like to
see this better engineered so that less computation is repeated for each
target. Should be easy; just needs to be done.
See also this note about Spaces in Path Names.
Projects handling ===
Generalized support for STLport at least ought to be integrated with
the system. It would be best if it was possible to use other standard library
replacements through the same mechanism.
How should the build system find STLport?
One possible solution is to use STLPORT_ROOT to specify the location and try to guess the names for the different versions by appending "STLport-4.0" or STLport-4.5". The algorithm might look like this (for version X.Y)
# If STLPORT_ROOT_X_Y is set, use this value to locate the header files.
# If STLPORT_ROOT is set, append "STLport-X.Y" (the directory name from the STLport archive) and use this value.
# If neither variable is set, complain to the user.
Full implementation and use of the module system will include a rule something
module local imported-modules ;
rule import ( module-name : rules-opt * : rename-opt * )
if ! ( $(module-name) in $(imported-modules) )
SEARCH on $(module-name:G=module@) = $(BOOST_BUILD_PATH) ;
include $(module-name:G=module@) ;
IMPORT [ CALLER_MODULE ]
: $(module-name) : $(rules-opt) : $(rename-opt) ;
We'll need to bootstrap the module system with something that imports the
``core'' module (which includes the above rule) into the global module.
[buy lipitor online] [buy lipitor] [[buy lipitor online]]
[buy fioricet online] [buy fioricet] [[buy fioricet online]]