From: Douglas Gregor (doug.gregor_at_[hidden])
Date: 2007-05-10 09:12:53
On May 10, 2007, at 6:53 AM, David Abrahams wrote:
> on Wed May 09 2007, Doug Gregor <dgregor-AT-osl.iu.edu> wrote:
>> The only one I'm not sure about is:
>> - It should be possible to build multiple variants of multiple
>> targets with multiple compilers from a single build command.
>> I think this particular requirement is actually a problem itself: it
>> only really helps Boost developers that want to quickly test on a
>> couple of compilers. The majority of users will typically use Boost
>> one just one compiler (especially those users picking up Boost for
>> the first time, who are most put-off by a complicated build system).
>> It's just as easy, if not easier, to keep separate build trees (one
>> per compiler) rather than cram everything into a single build tree.
> I've been thinking the same thing myself for some time.
> However, for me, the ability to quickly test on a whole mess 'o'
> compilers has been crucial to my ability to build portable C++
> libraries. So IMO it's still important to cover that use case
> somehow. Maybe that ends up being done with scripts?
I do this all of the time with autotools-based projects. I just have
a set of build directories, and I run the same command in each one
(which is trivial to script). I actually prefer this directory layout
to having everything under bin.v2, because it's very easy to find (or
remove) particular object files and executables for a certain
compiler/platform (instead of digging in, e.g., bin.v2/libs/signals/
build/gcc-4.3.0_c++0x/debug/link-static/), and it's easier to
parallelize the testing at a course granularity (since each
configuration is distinct).
My complaint with that requirement is that it has led to a design
that makes the simple case (one system compiler) complicated. It's
optimized for the more complicated cases that Boost developers need,
but it's not clear to me that there's much benefit gained from this
optimization over a simple top-level script.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk