Boost logo

Boost-Build :

From: Ali Azarbayejani (ali_at_[hidden])
Date: 2003-05-28 09:50:17


David Abrahams wrote:
>
> Vladimir Prus <ghost_at_[hidden]> writes:
>
> > Konstantin M. Litvinenko wrote:
> >
> >> VP> Yep, here's the duplication again....
> >>
> >> Yeah :( I think if library depends on another library than you should
> >> implicitly add <library> to usage requirements section.
> >
> > I recall Ali Azarbayejani was proposing to make <library> semantic more
> > user-friendly, but that discussion did not ended in anything. Need to
> > revisit the topic someday.
>
> Ali and I actually discussed this last Friday and came up with some
> solutions. Part of the answer is to give explicit control over
> property propagation. I hope Ali will post our conclusions by
> tomorrow (he has the notes).

I'm going to work more on this today...I could post our analysis so far,
but there are a lot of loose ends which I'd prefer to understand more
first.

We discussed propagation "up" (i.e. to dependents) of usage-requirements
and propagation "down" (i.e. to dependencies) of requirements. In
particular, currently all usage-requirements are propagated up no matter
what their attributes and currently all requirements are propagated down
only if the feature has attribute "propagated". We thought it is
required

(1) to have at least two attributes, like "propagated-up" and
"propagated-down", the former for requirements, the latter for
usage-requirements

(2) to have the attribute be of the individual property, not only of the
feature; the feature attribute is a default, but can be overridden on a
particular property. For example, most compiled libraries will have a
<include> property in usage-requirements that is NOT propagated whereas
most template libraries will have a propagated <include>.

However, I don't know if these suggestions completely address the
semantic issues. For example, I think it's odd that a library can be
specified as either a source or a property (and they're handled
differently...one is a source, the other is merely a dependency...which
I admit I don't completely understand yet). Related to this, we also
proposed sources being properties internally (even if we want to
maintain a separate argument for sources in the declarations), so that
it would literally be equivalent to have "a.cpp lib1" in sources or to
have "<source>a.cpp <library>lib1" in requirements.

These things all need to be worked out more though. Once I grasp all of
this better I will post a more complete proposal.

--Ali

 


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk