On Nov 13, 2008, at 12:31 PM, Vladimir Prus wrote:
Michael Jackson wrote:
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.
Err, I did not say that. I said that Boost.Build does not need any
up-front
build of anything -- if you want to run regressions with specific
properties,
it will build all that's needed.
- Volodya
That was my basic interpretation. Basically, if you are building the
regression tests then you will need all the variants because at some
point all the variants are most likely used.
I can start putting logic into the cmake files to make sure the proper
variants are built but it is just easier to build all of them if you
are going to be running tests. I am interested to hear all the
arguments either way.
_________________________________________________________
Mike Jackson [EMAIL PROTECTED]
www.bluequartz.net
_______________________________________________
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake