On Nov 26, 2008, at 9:32 AM, Vladimir Prus wrote:
Michael Jackson wrote:
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.
We seem to be miscommunicating on this point :-( Why
"all the variants are most likely used"? If I'm running test with
variant=debug link=shared, then I don't need variant=release, ever.
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.
You'll be just wasting disk space with 8 variants of libraries, where
only 1 is needed. And debug variants are huge.
- Volodya
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.
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. (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.
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? Was the boost community
wanting to move in another direction with the CMake build system? I am
just trying to figure out where I might want to put my efforts.
Thanks for all the helpful feedback.
_________________________________________________________
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
