on Wed Nov 26 2008, Michael Jackson <mike.jackson-AT-bluequartz.net> wrote:
> Taking a deeper look into this issue (by experimenting with bjam) this > is what I am seeing (at least on OS X). > > bjam errors on the side of building if I don't quite give it the right > information. For instance in the program_options testing I do the > following: > > bjam cmdline_test_dll toolset=darwin variant=debug link=static > > and I actually get a shared program_options library built, which is what the > regression test needs, but I don't actually get a static program_options > library > built. Because the regression test doesn't need it. That's not erring on the side of building; that's erring on the side of doing what's specified by the Jamfile if it conflicts with the command-line. There's some rationale for that (http://zigzag.cs.msu.su/boost.build/wiki/AlternativeSelection#Example2) even though Boost.Build doesn't hew to that rationale consistently. > I also noticed that if I start adding multiple configurations (like > single and multi-threading) I will get multiple versions of the > regression test created. I can't see what possible alternative you could have expected. > (Which answered another question that I was going to ask). > > Currently the CMake system will NOT do any of this. If this is the > behavior that is wanted then the logic will need to be added to the > cmake build files. IIUC, CMake doesn't naturally build multiple variants in one build command. It was my conclusion, along with Doug G., that such multiple-configuration builds should be handled by an external driver script rather than trying to get CMake to do something for which it isn't designed. I'm not sure how well that fits with Boost's testing regime, though. When I look at the Jamfile for program_options it seems to be specifying two specific configurations to test. > Some one will also need to add to the boost_add_test to make sure all > the variants of the test are correctly built if asked for. The logic > for all of this will be quite "interesting" to implement. > > Are these things that the boost community wants in the cmake system? > Basically to have the same behavior as bjam? IMO we should think very carefully before moving in that direction. There are lots of good design ideas in bjam but not everything we did there ultimately ends up helping. In particular, the "separate configuration step" design of cmake (and autoconf) seems to have some advantages over the "one big build step" approach of Boost.Build, and the former is linked, at least partially, to the "one variant per invocation" design of CMake. -- Dave Abrahams BoostPro Computing http://www.boostpro.com _______________________________________________ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
