From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-03-26 03:08:47
That's a reply to your <link-to> proposal. I think that it depends on my other
message ("Build request specification").
> lib b ;
> # Normally, how static or shared libraries depend on each other.
> # Note that using the low-level features <uses> and <link-to>
> # requires a redundant specification. Usually, even with many
> # template libraries, if you <uses>, you also <link-to>.
> lib a : a.cpp : <uses>b : : <link-to>b ;
Now we have
lib a : a.cpp : <uses>b : : <library>b ;
and the only difference is that usage requirements of 'b' are grabbed by
anyone using 'a'. I guess you explicitly don't want current behaviour by
> # Shorthand for above (proposed)
> lib a : a.cpp b ;
I comment on this in another message. The idea feels good, but it's orthogonal
to <link-to>. We can implement it now to automatically add <library>b to
usage requirements, or we can implement <link-to> and add <link-to>. Note
that <uses>b should not be added. Since 'b' is source of 'a', 'b's usage
requirements will be grabbed already.
> # Shorthand for above (proposed) (N.B. a client of lib "a" would
> # get <link-to>b; it wouldn't get <uses>b or <library>b...literally
> # shorthand for the above.)
> lib a : a.cpp : <library>b ;
OK. If we make the above work, we should make this work as well.
> # If you wanted to have a statically-linked DLL, you would have to
> # do something like this. This would somehow have to interact with
> # the <link> feature. Note the difference.
> lib a : a.cpp : <uses>b <link-to>b ;
IMO, this should be the same as
lib a : a.cpp : <library>b ;
else the semantic of <library> becomes too complex. I think that the
suggestion to make meaning of <library> depend of whether "lib" is linked
statically or dynamically would clearly fit here.
> # If, e.g., b's headers are in a's public interface, you might do
> # the following to expose b's usage requirements. (Again, from a
> # purist SW architecture point of view, I always recommend against
> # this sort of sneaky thing...but it comes up and this is how to do
> # it.)
> lib a : a.cpp : <library>b : : <uses>b ;
Using the shorter syntax you proposed, it's
lib a : a.cpp b : : : <uses>b ;
IOW, you explicitly export 'b' usage requirements to 'a''s client. BTW, it's
also equvivalent to
lib a : a.cpp : <uses>b : : <library>b ;
so there's still some redundancy, but I don't mind at all.
> # Executables
> exe e : e.cpp : <link-to>b ; # e merely links to b
> exe e : e.cpp : <uses>b <link-to>b ; # e directly uses b and links
> to b
> exe e : e.cpp b ; # same as above (uses and
> exe e : e.cpp : <library>b ; # same as above (uses and
We can have all of this now, except for the first one. So, to summarize, you
have two independent suggestions:
1. Make library target mean something reasonable in list of sources for other
libraries. I'm +0.5 on this idea. We'll need some work on to work on detail.
2. Add a <link-to> feature, which only links to library, but does not grab its
usage requirements. Now, if we force client to link to some library via
<library>b in usage requirements, we also force it to grab usage requirements
of 'b'. Again, I understand your motivation, but there's a couple of
- what should be default behaviour when lib is in sources of other lib. The
safer one that you propose (add <link-to> to usage-requirements), or the
behaviour of <library>. What's more usefull in practice.
- I don't like <link-to> which is <library> that does not grab usage
requirements. A new feature for this purpose sounds like overkill. Will we
want to create feature groups in future: one which makes some use of another
main target, and one which both makes some use and grabs usage requirements.
Would be nice to specify that we don't want to recursively propagate usage
requirements of a library. E.g
lib a : a.cpp : : : no-usage-requirements-propagate:<library>b ;
will do the same as
lib a : a.cpp : : : <link-to>b ;
But this scares me a little. We already have conditional properties and
adding a new syntax element without becoming ambiguous needs thought...
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