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
> > too burdensome to backslashify things explicitly when you know you'll
> > invoking a shell command. In fact, in v2 we can deal with this by
> > bottlenecking all setting of SEARCH and LOCATE through appropriate
> > the target class. In other words, build actions will be nicely isolated
> > layers from the high-level code.
> Hmm... now I really don't understand you ... to recall, your earlier
> > 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
> or from user.
> 2. Translate them back to backward-slahed from when passing to build
> 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
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
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