Re: [jamboost] Re: [V2] Completely confused.

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
> {
> whatever
> }
>
> Then clearly that's impossible because you can't invoke rules there.

I mean

rule html
{
whatever
}

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

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

- Volodya