From: David Abrahams (dave_at_[hidden])
Date: 2002-12-15 09:15:50
Vladimir Prus <ghost_at_[hidden]> writes:
F> David Abrahams wrote:
>> Wow, I just crashed bjam by using this rule. I notice it's
>> undocumented, also.
> It's documented somewhat at the end of "boost_build_v2.html". I'd have
> to move some docs to "readme.html", eventually.
>> The error happens here:
>> TARGET* t = search_for_target( arg1->string, arg2 );
>> Since arg1 is an empty list, it is NULL.
> That's a bug, that I'll fix right away.
>> I was wondering if we really need this builtin, since we have Glob and
>> 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 ]
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.
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.
Would a function which accepted gristed target names and an optional
sequence of paths to search in would fit more seamlessly into the
-- 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