Re: [boost] Boost.Build changes for 1.38

Subject: Re: [boost] Boost.Build changes for 1.38
From: Robert Ramey (ramey_at_[hidden])
Date: 2008-11-01 14:06:47

I'm interested in the process whereby these changes occur.

I would like to see

a)  trunk testing continue with the "last release" of bjam.
b)  the trunk testing to include testing of at least one boost tool - bjam.
c)  when trunk testing passes, then boost build changes can be
merged into the release - just as a normal library.  At this point,
the Boost Build from the release ready branch would be used
by trunk testing.

It's my understanding that boost.build has its own test suite so
implementing trunk testing should entail little or no extra work.
Though I would expect that as in testing of libraries, new problems
motivate the addition of new tests.  This is a good thing.

I believe that this would make implementing big changes in
boost build easier for everyone.

Robert Ramey

Vladimir Prus wrote:
> As we're nearing 1.37, and the time for big changes that follows
> after,
> I wanted to discuss one Boost.Build change I want to make.
>
> Right now, we have two ways to build Boost -- using bjam directly,
> and using
> configure and make (which are wrappers over boost.build). The first
> approach
> may be a bit hard, and the second is very nice when it works, but it
> leads to
> other problems:
>
> - users start to assume it's "real" configure, and get upset when
> various
> variables that CXXFLAGS have no effect
> - if users want to do anything custom, like mingw cross compilation,
> they have to go back to direct use of bjam anyway.
>
> So, I'd like to suggest a solution where building of boost involves
> three steps:
>
> 1. ./bootstrap.sh or ./bootstrap.bat
> This step just builds bjam and puts it into boost root
>
> 2. ./bjam [--build-type=complete] [--layout=xxx] [properties]
> configure
> This step:
> - Tries to detect what compilers you have
> - Figures which optional libraries you have, and which you don't
> (e.g. ICU)
> - Writes a file project-config.jam with all the discovered
> information.
>
> 3. ./bjam
> This step can be usually invoked with no parameters, reads the
> configuration information from project-config.jam, and builds
> everything.
>
> For new users, this solution is only marginally more complex that
> configure/make, and does not create the false impression it's
> autoconf. For power users, the file produced in (2) can be tweaked
> and extra options can be specified in (3). For all users,
> this means that various properties can be specified only once in (2)
> and need not be repeated on every build, which is clearly a
> convenient thing.
>
> Anybody has comments about this plan?
>
> - Volodya