BOOST WIKI | RecentChanges | Preferences | Page List | Links List

Showing revision 35
This page is devoted to an ongoing design discussion about the evolution of Boost.Build.


Knowledge Base

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.

Testing Framework

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:

STLPort support

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 particular toolset.

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.

Outstanding Issues

This section is devoted to issues that make me scratch my head. Discuss!

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.

Configuration and Installation


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.

Building semantics

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)

  1. If STLPORT_ROOT_X_Y is set, use this value to locate the header files.
  2. If STLPORT_ROOT is set, append "STLport-X.Y" (the directory name from the STLport archive) and use this value.
  3. If neither variable is set, complain to the user.

Module System

Full implementation and use of the module system will include a rule something like this:

    module local imported-modules ;
    rule import ( module-name : rules-opt * : rename-opt * )
        if ! ( $(module-name) in $(imported-modules) )
            module $(module-name)
                SEARCH on $(module-name:G=module@) = $(BOOST_BUILD_PATH) ;
                include $(module-name:G=module@) ;
            if $(rules-opt)
                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.

Per-project requirements and target pathes

[buy lipitor online] [buy lipitor] [[buy lipitor online]]

[buy fioricet online] [buy fioricet] [[buy fioricet online]]

BOOST WIKI | RecentChanges | Preferences | Page List | Links List
Edit revision 35 of this page | View other revisions | View current revision
Edited August 24, 2008 2:18 pm (diff)
Disclaimer: This site not officially maintained by Boost Developers