Re: [jamboost] More path problems

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

----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>

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

The point is:

1. native paths (and mixtures of forward and backward slashes) would be
legal input for all rules
2. In order to provide error-checkable and nicely-readable output we can
forward-slashify
3. The place where we backslashify paths is a dead-end: it's one or more
low-level methods of target class instances which set the Jam target name
and/or SEARCH and/or LOCATE at a low level, and the backslashified path
never comes back out. Even if it did come out, this backslashified path is
a perfectly legal path in all other contexts.
4. Note that we have a trivial way to forward-slashify at any time, with :T

This scheme reduces the risk of programming errors and reduces the burden
on programmers.

-Dave