From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-05-08 09:45:45
David Abrahams wrote:
> I have just been restoring the FAIL_EXPECTED rule for the Boost release,
> and ran into some problems when doing "jam -fcheck-jam-patches.jam" in
> tools/build/test. The -d+5 output is enclosed (the good news is that with a
> workaround those tests pass, so we should be able to integrate them into
> At the lowest level, the problem is that find-to-root is getting called
> with "." as the directory, which implies we really should be doing
> something like:
> local cwd = [ PWD ] ;
> find-to-root $(dir:R=$(cwd)) : ...
In which case the path found will be absolute. I'm not sure I like this idea
-- as I said previously, user should be present relative names and converting
absolute names back to relative is not easier than using relative ones in the
There was similar problem in project.jam, which I've fixed by changind
"find-jamfile" rule to use os.path module. Maybe, the same thing is needed
> At a higher level I don't know whether "." is to be considered a
> "normalized path" or not,
It is documented at the top of "os.path.jam". It is normalized path.
> and I don't know, for each rule in the call
> chain, whether it accepts normalized or native paths... so I don't know how
> to address this problem.
> Vladimir, do you remain unconvinced that having code outside of os.path
> manipulate two kinds of paths is problematic?
Frankly, I believe that 90% of the problems are due to $(something:P) usage.
We should eliminate that in the first place. About normalized/unnormalized
path: for me, there not too many places where conversion is needed. OTOH,
your point about eliminating "make"/"native" invocations, is very reasonable.
I'm not sure about your proposal of using forward slashes in paths on
windows, since "mkdir" and the company won't like them.
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