Re: [jamboost] More path problems

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-05-11 08:12:43

David Abrahams wrote:

> > 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"?

"ed" after "present" was omitted.

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

Does GLOB takes several directories?! Oh, I never realized that! I will 
rewrite 'find-jamfile' using this fact.

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

Hmm... now I really don't understand you ... to recall, your earlier wrote

> I believe we can work around this problem by having the NT platform
> representation use forward slashes instead of backward slashes.

Do you suggest that we, when on NT,
1. Translate paths into forward-slashed form when we get paths from "GLOB", 
or from user.
2. Translate them back to backward-slahed from when passing to build actions?

This seems very like 'make' and 'native' rules.

- Volodya