Re: [jamboost] More path problems

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-05-08 11:34:16

----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>
To: <jamboost_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
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
> > 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
idea
> -- 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
the
> first place.

OK...

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

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.

OK, thanks.

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

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

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

-Dave