Re: [V2] Completely confused.

From: David Abrahams (dave_at_[hidden])
Date: 2004-12-03 05:06:17

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.

>>> IIRC, there's "format" feature. Something like
>>> 
>>> bjam format=pdf
>> 
>> Hum. That really should be "boostbook-format=pdf." We still have
>> a slight tendency to reserve global names.
> 
> 
> BTW, 'format' is implicit feature, so you can write:
> 
> bjam pdf
> 
> too. Maybe this should be changed too. I wonder what Doug thinks.

Well, maybe output-format=pdf would be enough.

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

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?

> to make
> sure it's native path, and not portable one. Imagine foo/bar/a.cpp in
> sources on VMS. You'd need [foo.bar]a.cpp or whatever syntax is used
> there passed to the compiler.

Doesn't seem to be a big problem to me, yet.

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

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com