Boost logo

Boost-Build :

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 += [
>> : [ 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.


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

David Abrahams
dave_at_[hidden] *
Boost support, enhancements, training, and commercial distribution

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at