Re: [boost] Boost.Build changes for 1.38

Subject: Re: [boost] Boost.Build changes for 1.38
From: Alexander Sack (pisymbol_at_[hidden])
Date: 2008-11-04 16:43:08

On Sat, Nov 1, 2008 at 8:56 AM, Vladimir Prus <ghost_at_[hidden]> 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.

But to me this is more of an indication that the GNU build emulation
is not complete more so than configure/make wrappers is somehow
inherently flawed.  I believe the intent was to make the build more
friendly for new comers to the boost world.  Its a laudable goal and I
think its in boost best interest to make the build as friendly as
possible to non-boosters.

> 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.

Even though I think this has some merits, I think the main issues are:

- bjam is cryptic to non-boost.build people (even invocation)
- step 2 does involve some a priori knowledge of how you want to build
which is tricky
- build.sh doesn't really build anything, it bootstraps the build tool
itself which is again confusing

I would say that you would need some kind of option that would allow a
list of options and explanations similar to the `configure -help`
model otherwise I feel the above has move the barrier to entry a
little higher!  That's my 2 cents.

For the record, I think autoconf and friends are evil evil evil and
really are now overkill for most modern build environments (debugging
the libtool script can be a life changing experience).  But the fact
is most build folks and new comers are going to expect some kind of
build env that follows the "configure/make/make install" paradigm.  I
believe for 99% of the builds you can make this work properly but
perhaps I'm wrong.

I just don't understand why the configure script couldn't be a tad
more complete to get what you want?  :D

-aps