From: Doug Gregor (dgregor_at_[hidden])
Date: 2007-05-09 15:01:36
On May 9, 2007, at 2:36 PM, Rene Rivera wrote:
> Stefan Seefeld wrote:
>> FWIW, that's the typical GNU (autotools) build system procedure:
>> You create a build directory, run $(srcdir)/configure from there,
>> specifying any build options, and then 'make'.
>> Thus, different build variants would all end up in distinct
>> build directories, outside the source directory they were build from
>> (and are dependent on).
>> This approach is very natural for people working with autoconf /
> The problem with that approach is that it creates extra work that
> "users" must do to build. And any extra work the build system doesn't
> have control over raises the likelihood something will go wrong. For
> example, someone may forget that they need different dirs and
> accidentally reuse an existing one. Which could create all kinds of
> collisions and hard to diagnose errors.
I wonder what percentage of Boost users actually configure more than
one compiler with Boost.Build?
And how many users actually use any compiler other than the one
system compiler on their machines?
> In the same sense that Boost.Build is written on top of Boost.Jam, it
> might make sense to treat cmake as a backend to a slim build
> and control front end.
I strongly disagree with this approach, because it negates any of the
positive effects of using an off-the-shelf build system.
We expend a lot of effort maintaining Boost.Build, much of which
could be avoided if we bought into an existing system rather than
rolling our own. To switch to another "back-end" and still roll our
own... that would just be more wasted effort.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk