on Tue May 15 2012, Matthew Chambers <matt.chambers42-AT-gmail.com> wrote:
On 5/14/2012 2:36 AM, Dave Abrahams wrote:
Right. And 90% of use-cases don't want to take care of any of those things. That's why we wrote the rules as we did. Generating all the possible variants of a library is a packager's job, not part of the regular development workflow nor something that users regularly want.
If multiple library variants are desired to be supported, then it shouldn't just be part of the regular development workflow, it should be part of continuous integration.
Strike "just," and I agree with you. Most CI should go on somewhere away from the average developer's machine, although it's always good to be able to duplicate that procedure locally.
Boost.Build makes it much easier for me to create various build configurations targeting the different variants without cluttering the build files.
Right. And Ryppl is going going to add what's necessary in a layer on top of cmake. In fact, this would be a good time to find out what it is that you need so that we can implement it in the Ryppl build tool.
For an application that only cares about building one way, the extra abstraction isn't so useful, I agree. For libraries, it's very useful.
Why should "building-many-ways" be more of a concern for libraries than for applications? -- Dave Abrahams BoostPro Computing http://www.boostpro.com