Boost logo

Boost-Build :

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ć


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk