Re: [jamboost] SEARCH_FOR_TARGET

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
> problem.

Hmm.

>> 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.

Hmm Hmm.

>> Would a function which accepted gristed target names and an optional
>> sequence of paths to search in would fit more seamlessly into the
>> system?
>
> 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,
implicitly.

-- 
David Abrahams
dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution