From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2002-12-09 04:44:29
Vladimir Prus wrote:
> Markus Schöpflin wrote:
>>> 2. By using "source" rule as I've described in a previous
>>> source zlib : /path/to/zlib/installation/zlib : <shared>false ;
>>> As Dave said: "So you're using "source" as a way of adding a
>>> level of indirection with attached bulid requirements?"
>> Understood. Maybe we should think of a new name for the source
>> rule then. After all, it can do a lot more than just hold a
>> collection of sources now. I can't think of a really good name
>> right now, but maybe something like 'module' or 'alias'. The
>> latter might be a good choice, after all the rule aliases a name
>> with a set of sources or libraries and/or build requirements.
> True, "alias" is more general name. We could use both "source" or
> "alias" for convenience, or only "alias" to keep the interface
> simple. I'm for "alias" only.
Count me in.
>>> The last detail: <link> will be a composite feature and
>>> <link>static will expand to <link>static <link-runtime>static.
>>> Therefore, <link>static will really make everything static.
>>> OTOH, it's possible to override <link-runtime> explicitly.
>> Won't you have a problem with the recursive definition? Just
> Sorry, I'm not sure what you mean.
> Probably, something like
> 1. <link>shared <link-runtime>static in build request
> 2. <link>shared in some requirements, which overrides
> <link-runtime>static ?
> This could be problem, we'll have to think about it.
No, I didn't mean these. But you are right, this looks a little
problematic. At the very least, it leads to surprising behaviour if
there is no warning or error message.
> Or is there another issue?
I was just thinking about the expansion of the composite feature
<link> to the two features <link> and <runtime-link>. How will you
know that you don't have to expand <link> again and again? Or are
recursive compositions disallowed alltogether?
Hope this makes sense.
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