Boost logo

Boost-Build :

From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2008-02-15 19:06:56

   Hi Ruediger.

>> I believe it is 'bjam -j 2'. :-)
> Ummh - wouldn't it then make sense to make this the default in the main
> Boost Makefile for 1.35.0 ? It is just a wrapper around bjam, and simply
> adding "-j 2" to
> BJAM=./tools/jam/src/bin.linuxx86/bjam
> pretty much halfed my compilation time for Boost on a Core 2 Duo.

   I am not sure what you mean by the 'main Boost Makefile' as I see no
makefile in either the Boost SVN repository or the packaged release
distribution. Must be a wrapper added by whoever packaged your Boost
installation, and in that case that party should work this out.

> Likely many users will just call "make" and not bjam in order to compile
> Boost, and "-j 2" doesn't hurt on single processor machines.

   Not sure 'it doesn't hurt on sigle processor machines' as I do not
think that Boost Jam checks that this is a 2 processor machine and then
actually starts two parallel build action processes even on a single
processor machine. This obviously works worse than running a single
build action process at a time.

   We use -j %NUMBER_OF_PROCESSORS% for our Windows project development
builds but know that there are still things to iron out with this support.

   Examples that pop to mind at the moment:

   * If you use precompiled headers with multiple-processor builds using
msvc then the build system will currently not be aware of the fact that
the process compiling the first .cpp file needs to complete before the
second one can be started or else they both attempt to create the same
precompiled header. To work around this you need to run the build twice
when actually building the precompiled headers - once to build the
precompiled headers and get 'access denied' errors on some targets, and
again to compile those targets that did not get compiled correctly in
the first pass.

   * Again on Windows, when you have only one process left, bjam hogs
the other processor in an active waiting loop. There is a patch
currently being reviewed that fixes this problem.

   * I believe I some messages like 'Can not create process: ...' when
building Boost libraries this way using parallel builds a few times, but
I have not tested this extensively and tracked it down. I this is
connected it could be caused by something similar to what is causing the
precompiled header problem.

   Hope this helps.

   Best regards,
     Jurko Gospodnetić

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at