Synopsis
Boost.Build is a system for large project software construction built on - Boost Jam, a descendant of "Perforce Jam", an open-source make replacement[1]. Key features are: @@ -41,6 +41,19 @@
Status
+ + Boost.Build v1 is a useful, mature system. However, its design and + structure are not easily adapted to support some of the features + we'd like to see in the future. To this end, the Boost.Build + developers have begun work on v2 of Boost.Build, which will be + based around this + design document. If you are + interested in contributing to this effort or you wish to discuss + the design of Boost.Build, please post inquiries to the jamboost + mailing list at yahoogroups. +Here are some of the design criteria that led to these features. @@ -49,11 +62,13 @@
- Synopsis +
- Status +
-
Getting Started
-
-
- Installing Jam +
- Installing Boost.Jam
- Initiating a Build
@@ -128,7 +143,7 @@
- Command-line and Environment Variable Quoting -
- Jambase Replacement +
- Startup Behavior
- Rule Indirection
- Argument Lists
@@ -137,7 +152,7 @@
- Declaration -
- Local Variables +
- Variable Scope
- Local Rules
- The RULENAMES rule
- The IMPORT rule @@ -146,11 +161,11 @@
- Local for Loop Variables -
- While Loops
- Negative Indexing
- Target Binding Detection
- Return Code Inversion
- Ignoring Return Codes +
- Removing outdated targets
- The SUBST Rule
- The JAM_VERSION global variable
-
@@ -183,40 +198,26 @@
Getting Started
-Installing Boost Jam
- --
-
- The Boost Jam sources are located in the tools/build/jam_src - subdirectory of the Boost installation. - -
- The Jam - README contains basic installation instructions. - - -
- If you are installing on Windows, the make process may prompt you to set - some environment variables, and stop. Don't be alarmed; just follow the - instructions and start over. Please keep in mind that these variable settings - are case-sensitive. The variable settings necessary for bootstrapping - Jam are not needed once it has been built. -
- Note that the supplied Makefile may require editing for your - platform; see the Jam README for - details. The Makefile is used for bootstrapping Jam; it builds Jam into a - subdirectory called bin.platform. -
Installing Boost.Jam
+ + Follow these instructions to acquire + a bjam executable for your platform. Install it somewhere in your + path.Initiating a Build
-The easiest way to get going is to set the BOOST_ROOT - environment variable to point at the Boost installation directory, though - you can also set BOOST_ROOT on the command-line, using - -s.... You can use the TOOLS variable to indicate which - toolset(s) to build with, and the BUILD variable to describe how - you want things built. In most cases it should be sufficient to invoke Jam - with no variable settings. The following examples all assume that - BOOST_ROOT has been set in the environment. +
Boost.Build responds to several global variable settins. The + easiest way to get going is usually to use environment variables, + though you can also set them on the command-line, using + -sVARIABLE_NAME=value. In + addition to the toolset + configuration variables, you can use the TOOLS + variable to indicate which toolset(s) to build with, and the + BUILD variable to describe how you want things built. In + many cases it should be sufficient to invoke
bjam+ with no variable settings. -Here are some sample Boost Jam invocations: +
Some example Boost.Jam invocations:
@@ -277,7 +279,7 @@ jam -sBUILD=release@@ -227,7 +228,7 @@ -jam -sTOOLS=gcc my_target +bjam -sTOOLS=gcc my_target
default (debug) BUILD of @@ -235,7 +236,7 @@ jam -sTOOLS=gcc my_target - jam -fallyourbase-path -sTOOLS="msvc gcc"
+bjam -sTOOLS="msvc gcc"
default-build all with msvc and gcc @@ -243,7 +244,7 @@ jam -sTOOLS=gcc my_target set TOOLS=msvc -jam +bjam
Set an NT environment variable to always build with MSVC
@@ -252,15 +253,16 @@ jam-jam -sBUILD=release +bjam "-sBUILD=release <debug-symbols>on"
-release build all with default TOOLS:
+release build with debug symbols of all using + default TOOLS - jam -sBUILD="debug release"
+bjam -sBUILD="debug release"
debug and release build all.
This approach can be OK for quick-and-dirty tests, but environment variable settings tend to be unstable and non-uniform across users and machines, so @@ -659,7 +661,7 @@ exe my_target : my_source1.cpp my_source2.c ;> BUILD="debug release" # assuming Unix > export BUILD -> jam ... +> bjam ...
Platform-dependent - -sTOOLS="gcc msvc" + "-sTOOLS=gcc msvc" build with gcc and msvc @@ -679,18 +681,18 @@ exe my_target : my_source1.cpp my_source2.c ; build the release variant - -sBUILD="debug release" + "-sBUILD=debug release" build both debug and release variants - -sBUILD="<optimization>speed" + "-sBUILD=<optimization>speed" build a subvariant of the default variant (debug) with optimization for speed. - -sBUILD="debug release <runtime-link>static/dynamic" + "-sBUILD=debug release <runtime-link>static/dynamic" build subvariants of the debug and release variants that link to @@ -1361,60 +1363,38 @@ jam -sMSVCNT="\"\"C:\Program Files\Microsoft Visual C++\VC98\&quo set MSVCNT=""C:\Program Files\Microsoft Visual C++\VC98\"" - Jambase Replacement
+Startup Behavior
-New logic has been added to allow the built-in Jambase to be replaced - without recompiling Jam or adding command-line arguments. The user can - control the location of the build system by setting any of the JAMBASE, - BOOST_ROOT, or BOOST_BUILD_PATH environment variables (the settings of - these variables can also be overridden on the command-line using the - -sVARIABLE=... option). - -
The process is controlled by variables (in decreasing -precedence): -
-
-
-
- If JAMBASE is set, it specifies the path to the Jambase - replacement. Non-rooted paths are computed relative to the directory of - Jam's invocation. - -
- Otherwise, if BOOST_BUILD_PATH or BOOST_ROOT is set, - the build system filename is boost-build.jam. - -
- If the build system filename does not contain a path specification, - the build system file is searched for on $(BOOST_BUILD_PATH), - then at $(BOOST_ROOT)/tools/build. - -
- If BOOST_BUILD_PATH was not set, it will be set to - $(BOOST_ROOT)/tools/build. - -
- If neither JAMBASE, BOOST_ROOT, nor - BOOST_BUILD_PATH is set, we use the built-in Jambase (nearly - identical to the FTJam Jambase) - and load the user's Jamfile. Perforce Jam has this behavior, and it is - used for building Jam itself. Thus, when you rebuild Jam, these - variables should be unset. - -
The rationale for this behavior is as follows: -
-
-
-
- The Jam executable should allow the Jambase to be overridden to - implement other build systems without the user having any knowledge - of Boost, thus the JAMBASE variable. - -
- BOOST_BUILD_PATH is designed to be used to find all modules used by the build system, so that users - and system administrators may non-intrusively add modules to the system. - -
- Many Boost users already have BOOST_ROOT set. If a user - doesn't want to explicitly set up BOOST_BUILD_PATH, - BOOST_ROOT will supply reasonable behavior. - -
The Boost.Build v2 initialization behavior has been + implemented. This behavior only applies when the executable + being invoked is called "
bjam" or, for + backward-compatibility, when theBOOST_ROOT+ variable is set. +-
+
- We attempt to load "boost-build.jam" by searching from the + current invocation directory up to the root of the + file-system. This file is expected to invoke the + boost-build rule to indicate where the Boost.Build + system files are, and to load them. +
- If boost-build.jam is not found we error and exit, giving
+ brief instructions on possible errors.
+
+As a backward-compatibility measure for older versions of Boost.Build, +when the
+BOOST_ROOTvariable is set, we first search for +boost-build.jamin$(BOOST_ROOT)/tools/build+and$(BOOST_BUILD_PATH). If found, it is loaded and +initialization is complete. + - The
boost-buildrule adds its (optional) argument + to the front ofBOOST_BUILD_PATH, and attempts to + loadbootstrap.jamfrom those directories. If a + relative path is specified as an argument, it is treated as + though it was relative to theboost-build.jam+ file. + - If the bootstrap.jam file was not found, we print a likely + error message and exit. +
Rule Indirection
@@ -1573,67 +1553,62 @@ module your_module-
Local Variables
- module local expression ;
- - or -
- module local expression = - expression2 ; +Variable Scope
-The variables named by expression are given a distinct value - in the module, and can be manipulated by code executing in the module - without affecting variable bindings seen by other modules. If the - assignment form is used, expression2 is assigned to the - variables when the declaration is executed. For example: - -
+
- The only way to access another module's local variables is through a - rule defined in that module: + + The only way to access another module's variables is by + entering that module:Each module has its own set of dynamically nested variable + scopes. When execution passes from module A to module B, all + the variable bindings from A become unavailable, and are + replaced by the bindings that belong to B. This applies + equally to local and global variables:
-module M { - module local x = a b c ; - - rule f ( ) - { +-+module A +{ + x = 1 ; + rule f ( ) { - local x = 1 2 3 ; # temp override for M's x - N.g ; # call into module N, below + local y = 999 ; # becomes visible again when B.f calls A.g + B.f ; + } + rule g ( ) + { + ECHO $(y) ; # prints "999" } - ECHO $(x) ; # prints "a b c" - } } -module N { - rule g ( ) - { - x = foo bar baz ; # sets global x - M.h ; # call back into M, below - } +module B +{ + y = 2 ; + rule f ( ) + { + ECHO $(y) ; # always prints "2" + A.g ; + } } - -module M { - rule h ( ) - { - ECHO $(x) ; # prints "1 2 3" - } -} - -M.f ; -ECHO $(x) ; # prints "foo bar baz" +
+ Note that because existing variable bindings change whenever a + new module scope is entered, argument bindings become + unavailable. That explains the use of + "-module M { - rule get ( names * ) - { - return $($(names)) ; - } +rule peek ( module-name ? : variables + ) +{ + module $(module-name) + { + return $($(>)) ; + } } -ECHO [ M.get x ] ; # prints "a b c"$(>)" in thepeekrule + above. +Local Rules
@@ -1757,36 +1732,6 @@ for local y in $(x) ECHO $(y) ; # prints "1", "2", or "3" } ECHO $(y) ; # prints "4 5 6" -
- -While Loops
- - In classic Jam, some constructs are only possible using recursion: -
-The addition of while loops allows a simpler formulation for this and -many other rules: --# returns the part of $(list) following the first occurrence of $(symbol) -rule after-symbol ( symbol : list * ) -{ - if ! $(list) || ( $(symbol) = $(list[1]) ) - { - return $(list[2-]) ; - } - else - { - return [ after-symbol $(symbol) : $(list[2-]) ] ; - } -} --rule after-symbol ( symbol : list * ) -{ - while $(list) && $(list[1]) != $(symbol) - { - list = $(list[2-]) ; - } - return $(list) ; -}Negative Indexing
@@ -1852,8 +1797,27 @@ rule bind-rule ( target : path ) should be built anyway. Boost Jam extends NOCARE to apply to targets with build actions: if their build actions exit with a nonzero return code, dependent targets will still be built. + +Removing Outdated Targets
++
+ ++rule RMOLD ( targets * ) +
+Perforce Jam removes any target files that may exist on disk + when the rule used to build those targets fails. However, + targets whose dependencies fail to build are not removed by + default. The
RMOLDrule causes its arguments to be + removed if any of their dependencies fail to build. + +The SUBST Rule
+Note: the
SUBSTrule is deprecated in favor + of Perforce Jam's built-inMATCH rule, which has been + rolled into Boost.Jam. +The behavior of the SUBST rule for regular-expression matching and replacement (originally added in FTJam) has been @@ -1996,6 +1960,9 @@ rule BACKTRACE ( ) "change" a global variable by declaring a local of the same name. +
Many of the variables that are used to configure how Boost.Build works + internally are listed here with brief descriptions. +
Variables Associated with SubProject Identity
-
diff --git a/features.jam b/features.jam
index 7ce39666e..5680688c1 100644
--- a/features.jam
+++ b/features.jam
@@ -9,6 +9,7 @@ feature profiling : off on ;
feature struct-alignment : auto 1 2 4 8 16 ;
feature eh-model : default fast msvc ; # metrowerks only
+feature vtable-thunks : default on off ; # gcc only
feature threading : single multi ;
@@ -67,6 +68,7 @@ gTARGET_TYPE_REQUIREMENTS(DLL) =
- It can build for both environments - Unix emulation and Windows +native - with one compiler. +
- You can use the latest versions of GCC. The latest released
+version of MinGW GCC is 2.95.3, and building MinGW-specific versions
+of GCC 3.0.x has proven to be quite difficult. However, it's
+straightforward under Cygwin. Just be sure to configure with
+
--enable-languages=c,c++to disable other languages which +fail to build properly. + + - Download Boost, and unpack the full directory structure into some root directory. +
- Install the Boost.Jam executable if needed. Pre-builts are available. Make sure it's in your path. (Note: Boost requires an enhanced version of Jam; the basic version won't work.) -
- Set any environment variables required to run your compiler and related - tools from the command line. (It might be a good idea to verify your command - line compiler is working if you don't use it regularly.) If you don't want - to clutter your environment, see More on using the - tools for alternatives. + +
- Configure the command-line toolset(s) + you intend to use. It might be a good idea to verify your command + line compiler is working if you don't use it regularly. + +
- Optional: if you intend to build the Boost.Python library, set + environment variables to configure Boost.Build for your Python + installation. For more information, see these instructions. If you + leave this step out, Boost.Build will print a message about how to + do it, and will skip the build for Boost.Python. +
- Change to the Boost root directory. (The directory you unpacked the +
- Change to the Boost root directory. (The directory you unpacked the distribution into; unless you changed it, the name will be boost_n_n_n where - n_n_n is the release number. Among others files, it contains c++boost.gif, - and subdirectories boost, libs, more, etc.) + n_n_n is the release number. Among others files, it contains c++boost.gif, + and subdirectories boost, libs, more, etc.)
- Build the Boost libraries for your tools. The example - is for the GNU and Metrowerks compilers. +
- Invoke the build system, specifying the toolset(s) you wish to use. The example is for
+ the GNU and Metrowerks compilers. For more sophisticated jam
+ invocation options, see this documentation.
-
+
+bjam -sTOOLS="gcc metrowerks"bjam "-sTOOLS=gcc metrowerks" - The user sets up all of the environment for each toolset he wants to use,
- in the normal way. For example, for Microsoft VC++, ...vc98/bin is in the
- path, vcvars32.bat or equivalent has been invoked, etc. For Metrowerks
- CodeWarrior, cwenv.bat or equivalent has been called and ...Other Metrowerks
- Tools/Command Line Tools is in the path.
+ + - The user sets up all of the environment for each toolset he
+ wants to use in the normal way. For example, for Microsoft VC++,
+ ...vc98/bin is in the path, vcvars32.bat or equivalent has been
+ invoked, etc. For Metrowerks CodeWarrior, cwenv.bat or equivalent
+ has been called and ...Other Metrowerks Tools/Command Line Tools
+ is in the path. Many Unix operating systems come preconfigured
+ this way and require no user intervention.
-
- - The user doesn't want his environment cluttered with this junk and wants - to avoid the many other things done by the vendor's script files. Instead, - he or she sets variables which point to the toolset installation directories - (possibly in the Jamrules, or a user-setup.jam file invoked by the Jamrules). - These variables are used by the build system to locate the tools and invoke - the necessary setup. They are described in the comments in each toolset's - .jam file. + +
- The user doesn't want his environment cluttered with settings or
+ has non-standard installations for some of his tools. Instead, he
+ or she sets variables which point to the toolset installation
+ directories, either in the command shell environment or on the
+
bjamcommand-line. These variables are used by the + build system to locate the tools and invoke the necessary + setup. -
+
- HPUX
-- + +
- IBM Aix
+- - + Linux-x86
+- - - Microsoft Windows (includes Boost.Build files and boost-build helper - program).
-- + + Microsoft Windows + +
- SGI Irix
+- - + SUN Solaris
+- - + Compaq Tru64
+ +- + + Linux-PPC
+
true ; ##### Variant definitions #### COMMON_PROPERTIES ?= + default auto default single diff --git a/gcc-nocygwin-tools.html b/gcc-nocygwin-tools.html new file mode 100644 index 000000000..4495592b5 --- /dev/null +++ b/gcc-nocygwin-tools.html @@ -0,0 +1,234 @@ + + + + + + + Boost.Build - gcc-nocygwin toolset + + + + ++
+ ++ ++ +
+
+ +Boost.Build
+gcc-nocygwin toolset
+
+ +Introduction
+ ++This page describes the gcc-nocygwin toolset, which builds Boost using +the -mno-cygwin option of the Cygwin gcc compiler. This avoids +introducing dependencies on the Cygwin Unix-emulation layer, allowing +you to build Windows executables which are not dependant on +cygwin1.dll. +
++You could achieve the same results by using the MinGW version of gcc, +but the Cygwin compiler has two advantages: +
-
+
Configuration Variables
+ ++The gcc toolset responds to the variables shown in the following table, +which can be set in the environment or configured on the jam +command-line using
+-sVARIABLE_NAME=value. ++This toolset is an extension to the gcc-stlport toolset and therefore +also responds to all of the configuration variables for +gcc-stlport +and +gcc +in addition to those listed below. +
+ ++
+ + ++ +Variable Name +Semantics +Default +Notes ++ ++ +NOCYGWIN_+
STLPORT_
LIB_ID+ The name used to generate the stlport library names (corresponding + to the LIB_BASENAME variable in the STLport make files). + ++ mingw32 + ++ This forms the middle part of the STLport library + names, for example libstlport_mingw32_debug.a + +Prerequisites
+ ++Obviously, you'll need Cygwin installed on your Windows +system. Earlier releases of Cygwin came as monolithic packages, but +this switched to individually selectable components around 2000. If +you've got a recent installation, you'll have to make sure you've got +the optional mingw-runtime package installed. Have a look in +/lib/mingw to see if things like libmingw32.a and libcrtdll.a are +present, and that the directory /usr/include/mingw includes the +standard headers stdio.h etc. Install the additional package if +necessary. +
++You will also need the STLport standard library installed and fully +compiled (i.e. using its own iostreams) without any Cygwin +dependencies. This would be very easy if you had the real mingw +compiler installed, because the STLport distribution includes a +ready-made makefile for this, called gcc-mingw.mak. Making this work +with the Cygwin compiler requires a couple of changes to the file (see +below for details). Sooner or later there may +be a specific nocygwin makefile for STLport which will make this +easier. +
++Finally, you will need a Boost jam executable that was built for +Windows (aka NT). The Cygwin-built Boost jam is not suitable, +primarily because it executes commands via the Cygwin shell, which +doesn't handle backslashes in Windows pathnames. Until there is a +specific nocygwin makefile for Boost jam, it is probably best to +download the prebuilt executable for Windows. +
+ +Building with gcc-nocygwin
++Refer to the gcc-stlport +configuration section for details of the
+STLPORT_ROOT+variable, which you'll have to configure (at the very least). Make +sure to use Windows-style pathnames and not the /cygdrive/x/... style +(you're using the Windows native Boost jam, remember). ++Configure additional variables as described here if you want to +build the Boost.Python +library, making sure to point it at a Windows installation of +Python and not a Cygwin one. At the time of writing, the Python +example simple_vector.cpp fails to compile in debug mode +because of an incompatability with the STLport debugging STL +containers, but everything else should build properly. +
++If your STLport libraries don't have names like stlport_mingw32… +you will need to set the environment variable +
+NOCYGWIN_STLPORT_LIB_IDto replace the "mingw32" part of +the library names. ++Once your environment is right, you can +start the build as for any other +toolset, using the toolset name "gcc-nocygwin". If you want to +see exactly what's going on, try supplying jam the
+-d2+option to show the raw commands as they execute. ++If you work with COM or DirectX, you will want to force gcc to +generate vtable-thunks by including
<vtable-thunks>on+in the BUILD global +variable. If you're messing around with this stuff, make extra sure +that you build all your libraries (including STLport) with the same +vtable style. + +Boost threads library and gcc 2.95.3-5
++The Cygwin-special gcc release 2.95.3-5 does not include a thread-safe +version of libgcc.a, which prevents any of it's code being +thread-safe, even with the -mthreads option. If you're feeling lucky, +grafting in the thread-safe versions of _eh.o and frame.o from the +mingw 2.95.3 libgcc.a seems to fix the problem (give the hybrid +library a new name and adjust the compiler's specs file +appropriately). Later releases of the Cygwin compiler probably won't +suffer from this restriction, so you should definitely upgrade if you +want to use the threads library. +
+ + +Building a native STLport with Cygwin gcc
++The current release (4.5.3) of STLport does not include an extra +makefile to build the libraries with the -mno-cygwin mode of Cygwin +gcc, but you can use the existing
+ +gcc-mingw.makfile by +setting the +CXXFLAGS_COMMONvariable on your make command line, as follows: ++make -fgcc-mingw.mak "CXXFLAGS_COMMON=-mno-cygwin -I/usr/include/mingw" +
+ +You might also need to add-mthreadsand/or +-fvtable-thunkswithin the quotes, depending on what kind +of executables you ultimately want to produce. You can create multiple +versions of the libraries by setting a different +LIB_BASENAMEin each case, and set up a corresponding +value in the +NOCYGWIN_STLPORT_LIB_IDshell variable before building +Boost. + + +If you have built a newer version of Cygwin GCC from source, or +you've built an older one and configured it with +
--prefix=, you'll need to add the following +DYN_LINKvariable setting in order to get the GCC support +libraries into the library search path when the STLPort DLLs are +built: + ++"DYN_LINK=c++ -shared -L/usr/local/lib -o" +
+ +(substitute the path you passed to--prefix=for +/usr/local/libif you are using a non-standard +configuration). + ++Make sure that you're really compiling the STLport iostreams instead +of just wrapping the Cygwin gcc streams. The default behaviour for +STLport 4.x is correct, but it is possible to reconfigure this +manually. Refer to the documentation on selecting the IOStreams mode +if you're in doubt. +
+ ++ +Toolset and docs contributed May 2002 by +Raoul Gough + +
+ + \ No newline at end of file diff --git a/gcc-nocygwin-tools.jam b/gcc-nocygwin-tools.jam new file mode 100644 index 000000000..2a9479186 --- /dev/null +++ b/gcc-nocygwin-tools.jam @@ -0,0 +1,83 @@ +# (C) Copyright David Abrahams and Carlos Pinto Coelho 2001, 2002. +# Permission to copy, use, modify, sell and distribute this software +# is granted provided this copyright notice appears in all +# copies. This software is provided "as is" without express or implied +# warranty, and with no claim as to its suitability for any purpose. + +# +# gcc-nocygwin toolset by Raoul Gough (RaoulGough@yahoo.co.uk) +# +# This toolset builds boost on a cygwin system using the -mno-cygwin +# gcc option, which creates windows-native binaries (without any +# dependencies on cygwin1.dll). It requires an STLport built +# by mingw gcc, or maybe by cygwin gcc using the -mno-cygwin +# option, if you feel like messing with the STLport makefiles. +# +# Configuration: +# +# You need a boost jam executable that was built for NT, not +# cygwin. There are two reasons for this. Firstly, you need the +# NT jam variable to be set, and secondly, the cygwin build of +# boost jam executes commands via the cygwin shell, which doesn't +# handle backslashes in pathnames properly. +# +# Don't forget to set STLPORT_ROOT, either in your environment +# or in Jamrules in the boost installation directory. Also set +# BOOST_ROOT. Use native windows path names and not the +# /cygdrive/... style. +# +# Set NOCYGWIN_STLPORT_LIB_ID to set the STLport naming +# convention (default is "mingw32" which looks for libraries +# named like stlport_mingw32_stldebug.lib) +# +# Run boost jam from the boost install directory like this: +# +# jam -sTOOLS=gcc-nocygwin +# +# If things are going wrong, a handy jam option is -d2, which shows +# commands before execution. +# + +NOCYGWIN_STLPORT_LIB_ID ?= mingw32 ; + +{ + local GCC_STLPORT_LIB_ID = $(NOCYGWIN_STLPORT_LIB_ID) ; + + extends-toolset gcc-stlport ; +} + +flags gcc-nocygwin CFLAGS : -mno-cygwin ; +flags gcc-nocygwin LINKFLAGS : -mno-cygwin ; +flags gcc-nocygwin LINKFLAGSmulti : -mthreads ; + +#### Link #### + +# +# Duplicated from gcc-tools.jam (unfortunately) because we don't want +# IMPLIB_COMMAND to include -Wl,--export-all-symbols +# + +rule Link-action +{ + SPACE on $(<) = " " ; + # if we don't have a GNU linker then we can't pass any GNU-ld specific flags: + if $(NO_GNU_LN) + { + LNOPT on $(<) = ; + } + else + { + LNOPT on $(<) = "" ; + } + + OUTTAG on $(<) = "" ; + SOTAG on $(<) = ; + ACTION_1 on $(<) = ; + + # This will appear before the import library name when building a DLL, but + # will be "multiplied away" otherwise. + IMPLIB_COMMAND on $(<) = "-Wl,--exclude-symbols,_bss_end__:_bss_start__:_data_end__:_data_start__ -Wl,--out-implib," ; + DEPENDS $(<) : $(NEEDLIBS) ; + gRUN_LD_LIBRARY_PATH($(<)) += $(GCC_STDLIB_DIRECTORY) ; + gcc-Link-action $(<) : $(>) ; +} diff --git a/gcc-stlport-tools.html b/gcc-stlport-tools.html index 2a8a826e6..38369406f 100644 --- a/gcc-stlport-tools.html +++ b/gcc-stlport-tools.html @@ -23,14 +23,16 @@ Boost.Build's gcc-stlport toolset supports the GNU GCC compiler using STLport as a replacement -to the GNU libg++. This toolset is an extension to the -gcc toolset and therefore supports the same functionality. +to the GNU libg++. -
Configuration Variables
+Configuration Variables
The gcc-stlport toolset responds to the following variables which can be set in the environment or configured on the jam command-line using --sVARIABLE_NAME=value: +-sVARIABLE_NAME=value. This toolset is an extension to the +gcc toolset and therefore responds to all +of the GCC configuration +variables in addition to those listed below.diff --git a/gcc-tools.html b/gcc-tools.html index b7a294b03..198534888 100644 --- a/gcc-tools.html +++ b/gcc-tools.html @@ -28,9 +28,9 @@ also supports Cygwin GCC, though MinGW has its own distinct toolset. -
Configuration Variables
+Configuration Variables
-The gcc toolset responds to the following variables can be set in the +The gcc toolset responds to the following variables, which can be set in the environment or configured on the jam command-line using-sVARIABLE_NAME=value: diff --git a/gcc-tools.jam b/gcc-tools.jam index 0cc0151f9..2e583ecb0 100644 --- a/gcc-tools.jam +++ b/gcc-tools.jam @@ -168,6 +168,8 @@ flags gcc CFLAGSon : -pg ; flags gcc LINKFLAGS on : -pg ; flags gcc C++FLAGS off : -fno-rtti ; +flags gcc C++FLAGS on : -fvtable-thunks ; +flags gcc C++FLAGS off : -fvtable-thunks=0 ; flags gcc CFLAGS ; flags gcc C++FLAGS ; diff --git a/index.html b/index.html index 54f133290..c7a749450 100644 --- a/index.html +++ b/index.html @@ -14,95 +14,107 @@ Building
Boost Libraries
--
- -Read This - First! -Boost.Build is fairly new as yet. Some features - are missing or incomplete. Instructions for accomplishing basic tasks - (this page) are rudimentary. But enough functionality is working - well to make using Boost.Build worthwhile. The important - bits-and-pieces are all there - what's left is some of the relatively - minor glue to make the system smooth and easy to use. Secondary tasks like - copying libraries to installation specific directories are weak.
If - there isn't a configuration file (see Tools) available - for your favorite compiler, consider contributing one.
Note - that the underlying Boost.Jam build engine is mature software, and the - original Jam build engine has been - widely used for many years. The Boost specific extensions are well - on their way to becoming stable, and have begun to attract interest and - use outside of Boost.
Introduction
Preliminaries
Building Boost Libraries
-More on using the tools
-Tools available
+Configuring the tools
+Supported Toolsets
Boost.Jam executableIntroduction
-These instructions explain how to accomplish common tasks using Boost.Build, -the Boost Build System. The build system uses -Boost.Jam, an extension of the -Perforce Jam portable make -replacement.
-For tasks not covered here, see the full build -system documentation.
-Note that many Boost libraries are implemented entirely within their headers, -and so can be used without building object libraries. Libraries that do -require building object libraries first include the Boost Python, Regular -Expression, and Thread libraries.
+ +These instructions explain how to accomplish common tasks using +Boost.Build, the Boost Build System. The build system uses Boost.Jam, an extension of the +Perforce Jam +portable make replacement.
+ +For tasks not covered here, see the full build system documentation.
+ +Note that many Boost libraries are implemented entirely within +their headers, and so can be used without building object +libraries. Libraries that do require building object libraries first +include the Python, Regex, and Threads libraries. +
Preliminaries
Building Boost Libraries
+Using your operating system's command line interpreter, execute the following -steps. The sample commands given will work for both UNIX and Windows.
+steps. The sample commands given will work for both UNIX and Windows. +-
-
-
-
+chdir boost_1_27_0 // or whatever release you downloadedchdir boost_1_28_0(or whatever release you downloaded)More on using the tools
+Configuring the tools
The build system's toolsets are designed to work in either of two ways:
-
-
Tools available
+ +Supported Toolsets
+ +The following toolsets are supported by Boost.Build. For information + about configuring each toolset, click its name in the leftmost + column. +
+TOOLS Name @@ -110,79 +122,163 @@ steps. The sample commands given will work for both UNIX and Windows.borlandBorland command line compiler tools +Borland C++ comoComeau command line compiler tools +Comeau C++ compiler front-end for Windows, + using Microsoft Visual C++as a back-end. gccGNU GCC command line compiler tools +GNU GCC on Unix and Cygwin. gcc-stlportGNU GCC command line compiler tools, using the STLport library +GNU GCC on Unix and Cygwin, using the STLport standard library + implementation - +intel-win32Intel command line compiler tools under Win32 using the - Microsoft library +gcc-nocygwinGNU GCC Cygwin command line compiler tools running in + "no-cygwin" mode, using the STLport + standard library implementation (produces commercially redistributable + objects) - +intel-linuxIntel command line compiler tools under Linux +intel-win32Intel + C++ for Windows using the Dinkumware standard library in the Intel-required Microsoft + Visual C++ 6 or 7 + installation - +kccKAI command line compiler tools +intel-linuxIntel C++ for Linux - +metrowerksMetrowerks CodeWarrior command line compiler tools +kccKAI C++ - +msvcMicrosoft Visual C++ command line compiler tools +metrowerksMetrowerks CodeWarrior command-line tools - +msvc-stlportMicrosoft Visual C++ command line compiler tools, using the STLport library +mingwGNU GCC and associated tools in MinGW configuration (produces + commercially redistributable objects) - + +vacppIBM Visual Age C++ command line compiler tools +mipsproSGI + MIPSpro C and C++ + + +mipsproSGI + MIPSpro C and C++ ++ + +msvcMicrosoft Visual + C++ command-line tools. ++ + +msvc-stlportMicrosoft Visual + C++ command-line tools, using the STLport standard library + implementation ++ + +tru64cxxCompaq C++ + for Tru64 UNIX (versions prior to 6.5) ++ + + +tru64cxx65Compaq C++ + Version 6.5 for Tru64 UNIX ++ + +vacppIBM Visual + Age C++ command-line tools ++ +vc7Microsoft Visual + C++ command-line tools, in case you are using the +msvctoolset for a Visual + C++ 6.x.Unless otherwise specified, the library is assumed to be the one shipped with the compiler.
Additional tools can be supplied by adding an appropriate xxxx-tools.jam file to the tools/build subdirectory, where xxxx is the name of the tool being -added. If you write an additional toolset file, please submit it to Boost +added. If you write an additional toolset file, please submit it to Boost so others may benefit from your work.
+Boost.Jam executable
+Pre-built Boost.Jam executables are available for the following platforms:
-
-
RedHat Linux RPM packages are available:
-
@@ -221,11 +317,11 @@ the Boost.Jam executable yourself:
libraries created by the initial make in the jam_src directory.
-Revised 09 May, 2002 +
Revised 15 May, 2002
© Copyright 2001 Beman Dawes