Re: [boost] Boost Test Library and Boost.Build

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-10 17:48:17

From: "Gennadiy Rozental" <rogeeff_at_[hidden]>

> 1. MSVC compilation with Boost.Build
> a. Both libraries and test are compiled using boost build. But for some
> reasons jam does not invoke the programs compiled if I run bjam without
> targets. But it will run  if I specify the  target. See attached
> Jamfile.test.

The way testing.jam is currently defined, you can run all tests by building
the "test" target. It was set up this way so that you could stick testing
targets in regular Jamfiles, but they wouldn't be built unless explicitly
requested. We could easily make "all" dependent on "test" again, if that's
a problem.

> b. Let say I have 3 libraries compiled in the same directory, that have
> shared sources. It seems like a waste that boost build system recompile
> shared source 3 times. Is there way to make it compile once?

Not with v1. In Boost.Build v2, we have plans to prevent some of the
redundant builds.

> c.  Directory tree created by jam does not include OS we are building on.
> What will happened if I will start compiling in the same directory using
let
> say gcc from NT box and some UNIX box?

You'll be screwed. That's why you should use ALL_LOCATE_TARGET to set up a
separate build tree for each platform.

> 2. Sunpro
> While working on sunpro compilation I found 2 strange things:
>
> a. I have libraries Jamfile in build directory and test Jamfile in test
> directory. test are dependent on libraries. Let say test T is dependant
on
> library L and it is failing. I am changing some headers used in both T
and
> L. I am starting T compilation. First jam decides to rebuild some of the
L
> sources that depend on headers changed. It did. But then it failing
linking
> the library cause object files for sources that were not rebuild are
> missing.  jam happily ignore this failure and continue with T
compilation.

What's so strange about that? Jam does all the work it can. It can't link
T, because the library is missing, but it can try to compile T.

> b. Continue previous example. Let say T is compiled successfully. But
then
> some header are changed and I am recompiling again. Compilation fails,
but
> jam happily ignore it and continue to run stage

Jam continues with whatever work it can do. I don't think it will stage any
targets which fail to build, unless there's a bug in the stage rule.

> 3. GCC
> After minor changes  I made gcc 3.0 compile the libraries. But when I
> started to compile tests gcc produces a myriads of "template with C
linkage"
> errors. Look on gcc.out attached. Any help is greatly appreciated.

You probably have an extern "C" { ... } around your template declaration.
Try preprocessing the source to see what's going on.

-Dave