Re: [Boost-build] bjam not installed by default ?

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ć