Subject: Re: More path problems
Newsgroups: gmane.comp.lib.boost.build
Date: 2002-05-11 13:47:20 GMT (7 years, 7 weeks, 6 days, 12 hours and 23 minutes ago)
----- Original Message ----- From: "Vladimir Prus" <ghost <at> cs.msu.su> > > 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