Subject: Re: [Boost-build] bjam: names vs. boundname
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-08-26 02:47:39
On 08/25/2017 04:32 PM, Steven Watanabe via Boost-build wrote:
> On 08/25/2017 01:51 PM, Stefan Seefeld via Boost-build wrote:
>> playing more with bjam C code, I wonder whether I could highjack the
>> "name" vs. "boundname" distinction in the target definition. For that
>> I'd like to first understand how it is used in Boost.Build.
> The most important reason is that multiple names
> can refer to the same boundname. This is primarily
> used by the include scanner, to allow different
> include paths for the same header.
>> I'm reading the source code (starting in
>> and wonder how it might be used. In my case (faber), I use neither
>> SEARCH nor LOCATE, but am considering the possibility to change the
>> "boundname" later in the process (after targets have already been
>> defined, notably to change the actual filename if a property changes).
>> Would that work ?
> It should work as long as you don't try to change
> the boundname after the point where it would be
> set normally.
Can you define that a bit more formally, in terms of the conceptual
workflow ? (I assume referring to the code that would be where
"search()" is being called, yes ?)
>> If I refer to a target by name (to request an update, say), I'm using
>> the "name", rather than the "boundname", right ?
>> And which of the two is
>> being passed to actions ?
> The arguments are strings, and will be passed
> to the actions as-is except for $(<), $(>), and
> variables in the bindlist, which are converted
> to the boundname.
Ah, so $(<) and $(>) get actually substituted by target->boundname.
That's great, and exactly what I wanted to hear.
>> A bit of experimentation I've been doing yields confusing results,
>> though I may just have introduced some bugs.
> In Christ,
> Steven Watanabe
-- ...ich hab' noch einen Koffer in Berlin...
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