From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-05-08 11:34:16
----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>
Sent: Wednesday, May 08, 2002 9:45 AM
Subject: Re: [jamboost] More path problems
> David Abrahams wrote:
> > I have just been restoring the FAIL_EXPECTED rule for the Boost
> > 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
> > workaround those tests pass, so we should be able to integrate them
> > test_all.py).
> > 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
> -- as I said previously, user should be present relative names
do you mean "be presented with"?
> and converting
> absolute names back to relative is not easier than using relative ones in
> first place.
> 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
Probably. I'll leave that up to you.
However, here's another notable place where the code is complicated due to
the intervention of path normalization. os.path.glob would be unneeded (it
could just use GLOB), and find-jamfile could just use GLOB directly instead
of running that loop.
> > 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
> > 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)
> We should eliminate that in the first place.
Great, no problem.
> 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
...and my point about bugs creeping in where native and normalized paths
are the same in all tests cases.
> I'm not sure about your proposal of using forward slashes in paths on
> windows, since "mkdir" and the company won't like them.
I've already been through this on v1 in a few places. It's generally not
too burdensome to backslashify things explicitly when you know you'll be
invoking a shell command. In fact, in v2 we can deal with this by
bottlenecking all setting of SEARCH and LOCATE through appropriate rules in
the target class. In other words, build actions will be nicely isolated by
layers from the high-level code.
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