Re: [Boost-build] Questions on stagedir and cleaning

Subject: Re: [Boost-build] Questions on stagedir and cleaning
From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2012-07-24 07:29:09

   Hi.

> We see where someone ask our first question back in 2006 but see no
> answer. If you use the --stagedir flag it gets tampered with by adding
> "/lib". Is there away to not have the path extended? We see first that
> this flag is not discussed in the user documentation but we stumbled on
> it in the Jamroot script and see it posted in the email group.

   Just to make it clear - the --stagedir command-line option is part of 
the Boost library build and not part of the underlying Boost Build/Jam 
build system. That is why this is not mentioned in the build system's 
documentation.

   It is listed however in the Boost library project's help information 
screen (run 'bjam --help' in the Boost library's root folder).

   I'm not comfortable with modifying the Boost library build myself and 
do not know who is the actual maintainer for that.

> Next we do not seem to see any cleaning done if we are at the top of the
> Boost source and do a bjam variant=release threading=multi --clean or
> --clean-all.

   As for the --clean and --clean-all Boost Build options - I never 
really understood them completely or found them really useful, 
especially with a build spread through multiple projects. The problem is 
that really is many things you could mean when you say 'clean', e.g.
   - clean targets built by the current project
   - clean targets built by projects depending on this project
   - clean targets built by all projects touched in any way by the 
current project's build
   - clean targets built by any project having the same root project as 
the current project
or even something like:
   - clean targets built by 'all' projects, but do not clean these two 
as they are too rarely touched anyway and are way to expensive to 
rebuild :-)

   Personally, I find it cleaner to have my build scripts just count on 
Boost Build building its targets in a set of well known folders and then 
remove those folders directly when needed. Also, the '-a' command-line 
option works fine for 'rebuild anything used' :-)

   But feel free to dive in, do some research and say what it is exactly 
you would like a built-in 'clean' operation to do...

> In the past we have done our own custom make build process so that Boost
> and other COTS code fit into our build process model. We are now
> expanding our use of Boost and would rather not continue that work if we
> can figure out how to build with bjam and fit it into our software
> factory. Seems like we are pretty close on the build side, but the
> cleaning unless we do a brute force blow it all away and start over is
> not workable.

   We use a Python script for running our builds. Our own project builds 
are all implemented using Boost Build, but for some external libraries 
such as OpenSSL or Python - its native build system is triggered 
possibly only after fetching the correct release distribution, unpacking 
it and applying our own custom patches. Forcing everything to build 
using only Boost Build would take too much effort and can not be done 
for Boost Build itself, of course. :-)

> We have Boost 1.50.0 and pulled a nightly build of bjam. We have no user
> or site configuration, just plain Boost distribution and bjam build. We
> did do a bootstrap build of bjam. We are building on Red Hat 5.4, Windows
> 7, and Windows 2008 SR2.

   We use a separate Boost Build installation from the one distributed 
along with the Boost library releases and then use that one to build 
whatever projects are needed, including Boost. I personally always use 
the trunk, but generally our projects specify the exact revision they 
depend on and the project's Python build scripts then fetch and set up 
Boost Build just the same as any other external tool or library.

   Hope this helps.

   Best regards,
     Jurko Gospodnetić