On Nov 12, 2008, at 11:39 AM, David Abrahams wrote:
on Wed Nov 12 2008, Michael Jackson <mike.jackson-AT-bluequartz.net>
wrote:
Came across an interesting situation while doing some testing on the
CMake build system. I configured my build tree to be SHARED+MULTI-
THREADED+DEBUG. When I built I was almost immediately getting an
error
about not being able to link against boost_test_exec_monitor-mt-
shared. Which is wrong because test_exec_monitor is a static-only
library. As I walked through the CMake code to track down what was
the
problem I basically discovered for myself that if you have
BUILD_STATIC=OFF then NO static libraries will be built, which has
the
side effect of disabling any regression test that relies on the
test_exec_monitor.
Question: Is this desired behavior? (I wouldn't think so but I
would rather hear that from a boost dev)
Well, you'd need a Boost-CMake dev, of which there are few, to tell
you
what BUILD_STATIC=OFF is supposed to mean. However, my guess is that
it's really for deciding which library variants you're going to build
and install, not what can get built as part of a dependency chain.
Frankly, even in the build/install case, it seems implausible that
people could be unhappy when a static-only library is built statically
when the shared variant is requested. I would err on the side of
building rather than not building, and let people use --without-
libname
or whatever its CMake equivalent is if they want to leave it out.
I chatted with Volodya on the #boost irc channel and basically if you
are doing regression testing then all the variants are built. By
default a regression test will link against the debug, Single
Threaded, Shared Linking library. If those libraries are NOT available
then they are built so basically turning ON testing will enable ALL
variants to be built.
The doesn't affect the boost user who just wants to build the
libraries and install them. That user can still select what variants
to be built and installed.
Comment: I have a solution in place where I added another optional
argument to the boost_add_library macro that is located in
BoostCore.cmake. The argument is FORCE_VARIANTS followed by the type
of variant that you want to make. So the call to this macro for the
test_exec_monitor looks like the following:
boost_add_library(boost_test_exec_monitor
NO_SHARED
compiler_log_formatter.cpp
debug.cpp
execution_monitor.cpp
framework.cpp
plain_report_formatter.cpp
progress_monitor.cpp
results_collector.cpp
results_reporter.cpp
test_main.cpp
test_tools.cpp
unit_test_log.cpp
unit_test_main.cpp
unit_test_monitor.cpp
unit_test_parameters.cpp
unit_test_suite.cpp
xml_log_formatter.cpp
xml_report_formatter.cpp
FORCE_VARIANTS STATIC
)
This takes care of case where boost_test_exec_monitor was NOT being
built but I still have the case of adding a regression test does not
work. From boost/libs/config/test/CMakeLists.txt:
boost_test_run(limits_test DEPENDS boost_test_exec_monitor)
which will still fail because the current cmake code will look for
some other variant (MT-SHARED) of the boost_test_exec_monitor
library.
Problem.
Question: Should I somehow hard code into boost_test_run() a
conditional test for the test_exec_monitor library being needed and
link to the proper library?
Better than nothing, but...
Somehow seems "wrong" to do it that way.
Yep.
I really feel like I am missing something that probably was already
implemented.
IMO, NO_SHARED should mean when looking for a shared variant, pick the
static one instead... and vice versa for NO_STATIC if we have that.
You are correct and in fact it is that way in the CMake code.
Currently the way things are setup if I select to NOT have static
libraries built AND then try to build the regression tests then the
compilation will fail because the static libraries that the regression
test may be asking for are NOT built.
Probably the best approach is if the user enables the
"BUILD_TESTING" option then I'll have to enable all variants of the
libraries to also be built. This would parallel what boost.build does
currently.
Cheers,
--
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
