From: David Abrahams (dave_at_[hidden])
Date: 2002-12-15 10:16:35
Vladimir Prus <ghost_at_[hidden]> writes:
> David Abrahams wrote:
>> >> I was wondering if we really need this builtin, since we have Glob and
>> > True.
>> >> we can find out about SEARCH and LOCATE on any target.
>> > I thought about it before implementing the rule. The problem is that
>> > you'll have, for each included target,
>> > 1. take next directory in SEARCH
>> > 2. see if there's target of the same name placed there
>> > 3. otherwise, see if there's file of the required name
>> > for each direcotry in SEARCH. And (3) is exactly how common handling of
>> > "SEARCH" works. I'd rather reuse and augment existing core functionality
>> > than redoing everything in Jam code.
>> OK, but notice what I had to do in the latest testing.jam to replace
>> the effect of binding every source target.
>> for local s in $(srcs)
>> source-files += [
>> SEARCH_FOR_TARGET $(s:G=)
>> : [ on $(s) get-var-value LOCATE SEARCH ]
>> ] ;
> Sorry, I don't understand what this code is supposed to do....
For each target s named in $(srcs), it returns the path that will be
used as the target's binding.
> Please note also that SEARCH_FOR_TARGET works only during
> scanning/binding stage... it won't be usefull before.
Well, it does seem to work as intended where I've used it.
>> This would have been a bit easier if the rule acted in a way that
>> corresponded more-closely to what the rest of bjam is doing. For one
>> thing, I had to explicitly eliminate the grist on the target. For
>> another thing, I had to explicitly supply LOCATE and SEARCH.
> As I've said, it works during scanning only, where this is not a
>> Also, there's already a function in the core which does almost exactly
>> what SEARCH_FOR_TARGET is doing (it looks very much like a copy/paste
>> job). That's a bit too much code duplication for my level of comfort.
> Unfortunately, I found it very hard to avoid that duplication.
>> Would a function which accepted gristed target names and an optional
>> sequence of paths to search in would fit more seamlessly into the
> Don't know. What "optional sequence of paths" means? It already accepts a
> sequence of paths?
Hmm Hmm Hmm.
> Or you suggest putting "SEARCH" there, implicitly?
Actually, I was suggesting putting LOCATE followed by SEARCH there,
-- David Abrahams dave_at_[hidden] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution
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