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?
_________________________________________________________
Mike Jackson [EMAIL PROTECTED]
BlueQuartz Software www.bluequartz.net
Principal Software Engineer Dayton, Ohio
_______________________________________________
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
