From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-12-03 05:49:22
On Friday 03 December 2004 13:06, David Abrahams wrote:
> Vladimir Prus wrote:
> > On Friday 03 December 2004 12:25, David Abrahams wrote:
> >> .setup = [ common.path-variable-setting-command PYTHONPATH
> >> : $(.docutils-dir) $(.docutils-dir)/extras <PYTHONPATH> : exported
> >> ] ;
> >> It's more flexible, and raw "<" and ">" are illegal in most path
> >> systems anyway.
> > Cool. And should be easy to implement. Though, maybe, "$" is even
> > more intuitive?
> Yes, better.
This is now implemented.
> >>>> I feel like I'm beating a dead horse here, but requiring all
> >>>> this conversion between native and portable representation
> >>>> outside of path.jam seems like an incredibly unwieldy and
> >>>> inefficient thing for the programmer. Why shouldn't path.jam
> >>>> just handle this for us internally?
> >>> I haven't figured how it could do this.
> >> Seems simple to me:
> >> 1. Pick a portable path representation that has the property of
> >> being either:
> >> a. identical to the corresponding native path, or b. lexically
> >> distinguishable from any native path
> >> for every OS you want to support
> >> 2. functions that manipulate paths in path.jam take note of whether
> >> paths are native or portable coming in, and produce the same kind
> >> of path going out.
> > But then you'd still need to use 'path.native' in actions
> if by actions you mean
> actions html
> Then clearly that's impossible because you can't invoke rules there.
> So you must be talking about something else. The system could perform
> the translation to native paths when forming the Jam target names and
> SEARCH/LOCATE settings. What else is there?
The path which are formed by the user in rules attached to actions, like
> >> But maybe I'm missing something important.
> >>> You're right that path.make/path.native can be boring, especially
> >>> in interpreted language where you can declare all paths as
> >>> boost::filesystem::path.
> >> ?? You're not using the type declaration feature are you?
> > Oops, no. I never got around to checking how that feature affects
> > performance, and then I just forgot about it :-(
> So I wondered what you meant about declaring paths as
> boost::filesystem::path in an interpreted language?
Did I omitt "n't" from "can" again ;-) I mean that in interpreted language
it's not easy to declare certain type and have automatic conversion to and
form that type, like string -> path in boost::fs.
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