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

Reply via email to