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

From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2002-07-10 19:12:29

> > 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.

I was trying to use ALL_LOCATE_TARGET. I use it for building in the
directory boost/libs/test/build. I defined it as ./DEBUG. To my surprise it
created directory boost/Debug as a sparate build tree.

>
> > 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.

No. You did not get it. Here the order of actions:

1. I successfully compiled library L from L_source1.cpp and L_source2.cpp
2. I compiling test T from T_source.cpp and it's failing
3. I change header that is included both in T_source.cpp and L_source1.cpp.
4. I restarting T compilation.
5. Jam first found that it need to recompile L_source1.cpp.
6. Next It tries to relink library L. And it *fails*, cause L_source2.o is
missing.
7. Jam happily ignore it and continue with compilation of T_source.cpp
8. Jam link T_source.o with wrong version of library L.

In my case it worked and linked cause of the nature of changes I made. But
in general it could dangerous.

>
> > 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.
>

I rechecked. run rule continue with link even if compilation fails.

> > 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.

I don't think so. It from gcc STL implementation. Look onto gcc.out. Here an
example:

/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3
/stl_alloc.h:142: template with C linkage

>
> -Dave
>

Gennadiy.