Re: [boost] Why Boost.Build?

Subject: Re: [boost] Why Boost.Build?
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2011-03-29 23:51:52

AMDG

On 03/29/2011 06:48 PM, Dave Abrahams wrote:
> At Tue, 29 Mar 2011 17:46:48 -0700,
> Steven Watanabe wrote:
>> On 03/29/2011 05:04 PM, Dave Abrahams wrote:
>>>
>>> Part of that is because the design tries to do too much.
>>> Specifically, the production of multiple build configurations with a
>>> single build command offers most users no benefit in exchange for the
>>> enormous complication it causes in design, implementation, and
>>> especially in writing build instructions (Jamfiles in our case).
>>
>> Whatever you're talking about here, it's outside of
>> my experience. I have never written a Jamfile that
>> was made significantly more complex by the fact that
>> multiple configurations can be built at once.
>
> Then you either haven't done anything outside of the absolute basics
> (which I know is not the case),

The absolute basics have served me well.
It's true that I've done more sophisticated
things, but not in any way that's affected
by this.  I know (theoretically) that it
can make non-trivial platform specific
configuration harder, but that has never
affected me, because I generally only
write portable C++ with no dependencies
outside Boost.

> or you can't see the complexity for
> some reason.
>

I've written a lot of Jamfiles that look like:

run test1.cpp ;
run test2.cpp ;
compile test3.cpp ;
...

The biggest source of complexity in documentation
Jamfiles is setting all the parameters for xsltproc
and doxygen--no way out of that.

The only compiled library I've written Jamfile for
was for Boost.Random, which is about as basic as it
gets.

All the toolset specific configuration I've ever needed
can be handled by conditional features like
<toolset>msvc:<warnings>all, which is at least as
clean as any alternative.

I've done a fair amount of work with the documentation
tools, but inside a generator, you are only dealing
with one build variant at a time anyway.  The same
goes for the template profiler.

>>> For
>>> the few who do benefit from the feature, the ability to build multiple
>>> configurations easily could have been written as another layer that
>>> invokes the build system multiple times.
>>>
>>
>> I disagree.  Being able to build multiple variants of libraries is
>> pretty much a must-have on Windows, given that debug and release are
>> not necessarily ABI compatible.
>
> Of course it is.  But you don't have to do it in one invocationi of
> the basic build tool.  You could configure builds from different root
> build directories.

You can but it isn't quite as good as it doesn't
make it easy to share things between configurations.
Not that this ability is particularly important
to me, but I have used it.

> And then yous can automate that to make it
> seamless, if that's what you need.
>

Would it really be seamless?  I'm inclined
to doubt it.

>> I guess it doesn't matter much to me /how/ it's handled,
>
> *Exactly*.
>

Well, obviously it *does* matter to *you*.

>> but it can't be treated as an afterthought that doesn't really
>> matter.
>
> I didn't say it doesn't matter.  I said they way we dealt with the
> requirement made the solution more complex for everyone.
>

I think "everyone" is a huge exaggeration.
The kind of tasks for which it matters should
not be pervasive.  If they are, then Boost.Build
has failed much more fundamentally, or it's
simply being misused.

In Christ,
Steven Watanabe