Re: [Boost-build] <build>no propagation

From: J. van der Wulp (jwulp_at_[hidden])
Date: 2006-11-24 10:02:48

Hello Vladimir,

Thanks a lot for the speedy response.

I use the current CVS version with some minor changes in
tools/darwin.jam tools/gcc.jam and tools/testing.jam.
I have partially applied a patch to darwin.jam to add support for
building univeral binaries. I've changed some paths in testing.jam to be
able to use the test framework on our own libraries and tools. And in
gcc.jam I've split the USER_OPTIONS variable into USER_OPTIONS_CXX and
USER_OPTIONS_C because we had C specific options that produce warnings
when given to g++.

Ive created a simple project with four libraries and trivial source
files. The libraries are: A, B, C and D and E is an executable.

project test ;

lib A
      : A.cpp
      : <build>no
      :
      : <build>no
      ;

lib B
      : B.cpp
      ;

lib C
      : C.cpp
        A
      ;

lib D
      : D.cpp
        C
      ;

exe E : E.cpp D ;

The output of a clean build of the project that is attached gives:

...found 26 targets...
...updating 13 targets...
MkDir1 /tmp/MCRLC/bin/nobuild
MkDir1 /tmp/MCRLC/bin/nobuild/gcc-4.1.1
MkDir1 /tmp/MCRLC/bin/nobuild/gcc-4.1.1/debug
MkDir1 /tmp/MCRLC/bin/nobuild/gcc-4.1.1/debug/address-model-32
gcc.compile.c++ /tmp/MCRLC/bin/nobuild/gcc-4.1.1/debug/address-model-32/B.o
gcc.link.dll /tmp/MCRLC/bin/nobuild/gcc-4.1.1/debug/address-model-32/libB.so
MkDir1 /tmp/MCRLC/bin/nobuild/gcc-4.1.1/debug/address-model-32/build-no
gcc.compile.c++
/tmp/MCRLC/bin/nobuild/gcc-4.1.1/debug/address-model-32/build-no/C.o
gcc.link.dll
/tmp/MCRLC/bin/nobuild/gcc-4.1.1/debug/address-model-32/build-no/libC.so
gcc.compile.c++
/tmp/MCRLC/bin/nobuild/gcc-4.1.1/debug/address-model-32/build-no/D.o
gcc.link.dll
/tmp/MCRLC/bin/nobuild/gcc-4.1.1/debug/address-model-32/build-no/libD.so
gcc.compile.c++
/tmp/MCRLC/bin/nobuild/gcc-4.1.1/debug/address-model-32/build-no/E.o
gcc.link /tmp/MCRLC/bin/nobuild/gcc-4.1.1/debug/address-model-32/build-no/E
...updated 13 targets...

Hope it helps.

Best regards,

Jeroen

Vladimir Prus wrote:
> On Friday 24 November 2006 14:15, jwulp_at_[hidden] wrote:
>> Hello Everyone,
>>
>> I am currently involved in doing maintenance on the MCRL2 toolset. This is
>> a set of tools build on top of a variety of libraries such as ATerm, SVC,
>> libXML, wxWidgets, and a couple more. The fundament consists largely of the
>> ATerm library; so almost all tools use it therefore there is a strict
>> dependency. The toolset cannot be build without the ATerm library. No
>> problems so far.
>>
>> The problems start when there is a hierarchy of libraries and somewhere
>> below in the hierarchy a library is not available. Using the build feature
>> the lower level library has <build>no in its requirements (and usage
>> requiements). The build feature is nicely propagated upward following the
>> reverse dependencies; but it has no effect. Tools as well as libraries are
>> still being build with a directory element build-no in the target names.
>>
>> Is there a reason why the <build>no does not have an effect when it is
>> added via usage requirements? Is there another way to achieve the desired
>> effect?
> 
> It had the desired effect for me, at least once. Please specify the version of 
> Boost.Build you're using and provide a simple self-contained archived project 
> that reproduces this problem.
> 
> Thanks,
> Volodya
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
>