Re: [jamboost] Re: Problems with header-only lib

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-06-15 06:54:22

On Thursday 09 June 2005 06:51, David Abrahams wrote:

> Okay, I fixed this part. The problem was a mistaken dependence on
> the base-target-type feature, which I got from the prior state of
> msvc.jam:
>
> 1.28 (vladimir 06-Jul-04): flags msvc.compile CFLAGS
> <base-target-type>CPP : /EHsc ;
>
> I'm not sure how it ever worked, in fact. Can you explain how
> <base-target-type>CPP would have ever been satisfied when trying to
> produce an OBJ?

Frankly, I have no idea -- I don't see that feature set to any value anywhere 
in the code.

> >> Also, note that most of the time usage requirements are free features.
> >> I'm not sure that propagated features as usage requirements will quite
> >> as expected. For example
> >>
> >> rule copy.cpp /boost/test//minimal some_other_lib ;
> >>
> >> might propagate asynch-exceptions=on from minimal to 'copy.cpp', but I'm
> >> pretty sure it won't be propagated to some_other_lib -- because first
> >> all sources are built, and only then usage requirements for all sources
> >> are added to build properties.
> >
> > Hmm, yes... well, I admit that I would not have expected it to be
> > propagated to some_other_lib in that case, but it's also obvious to me
> > that it needs to be propagated that way. So this looks like a serious
> > architectural problem.
>
> Of course, this part is still a problem, and really needs to be
> properly resolved.

It's not "architectural problem", if by architecture you mean code design. 
It's more like specification issue -- I don't know what's the right behaviour
would be.

In the example:

run copy.cpp /boost/test//minimal some_other_lib ;

we first pass all build properties to dependencies. Then we collect usage
requirements from dependencies and build copy.cpp. If dependencies return
only free features in usage requirements, it's fine, because free features are 
not propagated anyway.

But with non-free features -- should we add usage-requirements from 'minimal' 
to properties used for building 'some_other_lib'? Or add usage-requirements
from 'some_other_lib' to build properties for 'minimal'. Or add 
usage-requirements?

What if adding usage requirements of 'some_other_lib' to build properties for
'minimal' change the selected alternative of 'minimal' and so changes the 
usage requirements from 'minimal'?

In order to allow propagating non-free properties in usage reqirements to
other dependencies we need a very detailed spec saying how it should work, and 
so far I have no ideas what's the right semantic is.

- Volodya

-- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2