no propagation

On Friday 24 November 2006 14:15, jwulpwin.tue.nl 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

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/buil
d-no
gcc.compile.c++
/tmp/MCRLC/bin/nobuild/gcc-4.1.1/debug/address-model-32/buil
d-no/C.o
gcc.link.dll
/tmp/MCRLC/bin/nobuild/gcc-4.1.1/debug/address-model-32/buil
d-no/libC.so
gcc.compile.c++
/tmp/MCRLC/bin/nobuild/gcc-4.1.1/debug/address-model-32/buil
d-no/D.o
gcc.link.dll
/tmp/MCRLC/bin/nobuild/gcc-4.1.1/debug/address-model-32/buil
d-no/libD.so
gcc.compile.c++
/tmp/MCRLC/bin/nobuild/gcc-4.1.1/debug/address-model-32/buil
d-no/E.o
gcc.link
/tmp/MCRLC/bin/nobuild/gcc-4.1.1/debug/address-model-32/buil
d-no/E
...updated 13 targets...

Hope it helps.

Best regards,

Jeroen


Vladimir Prus wrote:
> On Friday 24 November 2006 14:15, jwulpwin.tue.nl 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
> 


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

On Friday 24 November 2006 18:02, J. van der Wulp wrote:

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

Thanks. I have reproduced the problem and hopefully fix it
tomorrow. But, just 
to clarify -- is it fine for your that if <build>no is
propagated, then 
nothing at all will be built? Including any install targets
you might have -- 
nothing.

Thanks,
Volodya
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Hello Vladimir,

Vladimir Prus wrote:

>> The output of a clean build of the project that is
attached gives:
> 
> Thanks. I have reproduced the problem and hopefully fix
it tomorrow.

That would be great; you have all done an amazing job so far
with Boost 
Build v2.

> But, just to clarify -- is it fine for your that if
<build>no is propagated, then 
> nothing at all will be built? Including any install
targets you might have -- 
> nothing.

Yes, I think it is the most intuitive. That is, if
executable A cannot 
be build due to propagation of <build>no and
executable B can be build, 
then it would be nice if executable B is installed. For
example:

exe A : A.cpp some-library-with-build-no ;
exe B : B.cpp ;

stage install
       : A
         B
       : <location>/something/bin
       ;

For our application I do not care about any library that A
depends on 
cannot be build and/or installed. Our toolset currently only
builds and 
installs those libraries that are actually needed by the
tools thanks to 
Boost Build (which is a great feature I think).

Thanks a lot,

Jeroen
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

On Friday 24 November 2006 23:48, J. van der Wulp wrote:
> Hello Vladimir,
>
> Vladimir Prus wrote:
> >> The output of a clean build of the project
that is attached gives:
> >
> > Thanks. I have reproduced the problem and
hopefully fix it tomorrow.
>
> That would be great; you have all done an amazing job
so far with Boost
> Build v2.
>
> > But, just to clarify -- is it fine for your that
if <build>no is
> > propagated, then nothing at all will be built?
Including any install
> > targets you might have -- nothing.
>
> Yes, I think it is the most intuitive. That is, if
executable A cannot
> be build due to propagation of <build>no and
executable B can be build,
> then it would be nice if executable B is installed. 

> For example: 
>
> exe A : A.cpp some-library-with-build-no ;
> exe B : B.cpp ;
>
> stage install
>
>        : A
>
>          B
>
>        : <location>/something/bin
>
>        ;

In this case, the <install> target will get
<build>no -- since usage 
requirements are propagated all the way up. Do you suggest
that 'install' is 
specially coded to still install the other targets?

What precisely are you trying to achieve with
<build>no in properties? Do you 
want to avoid compiling lots of source files that depend on
missing libraries 
and won't likely compile anyway?

- Volodya
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

> 
> In this case, the <install> target will get
<build>no -- since usage 
> requirements are propagated all the way up. Do you
suggest that 'install' is 
> specially coded to still install the other targets?

Yes. To me it seems seems a natural choice. We maintain a
toolset with 
lots of tools. It can be that some tools cannot be built
because library 
X or Y is not installed. But the user accepts this and wants
to install 
the rest of the tools that can be build. I don't know how
difficult this 
would be to realise at this moment, but to me using the
build property 
looked like the perfect solution.

> 
> What precisely are you trying to achieve with
<build>no in properties? Do you 
> want to avoid compiling lots of source files that
depend on missing libraries 
> and won't likely compile anyway?

Yes this is exactly the intention. I want to use the build
property as a 
  filter method. The problem we face at the moment is that
some 
libraries and binaries are being build that should not build
because for 
instance libXML is not available. To do this the site-config
contains an 
alias target with the same name as the normal library
target, with 
<build>no in requirements and usage-requirements. Is
there a better way 
to solve this same problem?

Jeroen
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build