On Mon, May 21, 2012 at 12:47 PM, Dave Abrahams <dave@boostpro.com> wrote:
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.
My own local workflow is to develop via IDE (Visual Studio latest production release) and then when those tests pass, kick off bjam against many compilers (currently 7). For Filesystem, some of the tests are static, some are shared. I really should test both debug and release builds, although I'm not doing that now. I prefer results to be reported via an HTML table, but am willing to write the program to generate that HTML page, as long as the test results are available in some easy to parse form.
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 me, it is pretty much what bjam does now. Such as being able to specify: * Test specs invoke build specs if needed. * Compile, link, or run test, where pass|fail can be a report of no errors or errors. * Define macros, globally, per test, or per platform. * Define compiler or linker switches, globally, per test, or per platform. * Specify macros, switches, or other config details based on static, shared, debug, or release builds. * Be able to add or override macros, switches, or other config details from the command line. * Be able to add or override macros, switches, or other config details from a user config file. Presumably CMake already handles most of that. --Beman