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 _______________________________________________ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
