Michael Jackson wrote: > > On Nov 29, 2008, at 2:59 AM, Vladimir Prus wrote: > >> David Abrahams wrote: >> >>> >>> 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. >> >> Yes, it does. I think that for compiled libraries, it's a good idea to >> have both static and shared linking tested, whereas for header-only >> libraries, the chances that static/shared linking affects anything are >> close to zero. Therefore, test arrangement where header-only libraries >> are tested in one variant, and compiled libraries are tested in >> both static and shared variants appears to be a reasonable compomise >> between testing speed and coverage. >> >> - Volodya > > > So are you saying you would want to see cmake test all variants in a > single build directory or have multiple build directories, one for > each variant?
It want to have both shared and static flavours of program_options tested without running all the Spirit (*) tests in both modes. I presume this means that it should be possible to build and test both shared and static flavours of program_options in a single build tree. (*) Spirit is an example of a library that is both advanced enough to require non-zero testing resources, and which is header-only. - Volodya _______________________________________________ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
