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