On Nov 28, 2008, at 4:49 PM, 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.
Didn't know about that page. Thanks. It does help explain what I am
seeing.
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.
No alternative, just a newbie noticing (and verifying) behavior.
(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.
CMake's approach would be to make a separate build directory for
each build variant that was to be compiled/tested. So on Linux for
example you would potentially end up with 16 build directories. At
this point there is "support" for multiple variants within one CMake
build directory which is sort of "abusing" cmake a bit but does seem
to work at least for building the libraries.
In a "CMake" world and using the example from above, if a test
requires a static-multi-threaded build of a library BUT the user has
asked for a dynamic-multi-threaded then that test would not be built.
This is the current implemented behavior. This means that there is NO
attempt to build a static-multi-threaded library because a test
required it.
The test reporting will have to make these configuration choices
clear so that results can be easily and quickly reviewed.
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
External build scripts and such could be a reasonable choice. The only
thing I don't like about external scripts is that they are generally
NOT cross-platform and you end up writing a script for windows and one
for Unix.
I'm happy to help the boost community implement what ever style we
decide on in the end.
_________________________________________________________
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
