Re: [V2] Completely confused.

From: David Abrahams (dave_at_[hidden])
Date: 2004-12-03 04:25:45

Vladimir Prus wrote:

> On Friday 03 December 2004 11:43, David Abrahams wrote:
>
>>
>> .setup = [ common.path-variable-setting-command
>> PYTHONPATH
>>
>> : $(.docutils-dir) $(.docutils-dir)/extras
>> : exported ] ;
>>
>>Great! But what if I wanted the current value of PYTHONPATH
>>incorporated there somehow? ;-)
>
>
> If you look at testing.jam you'll figure out that I use
>
> if [ os.name ] = NT
>
> :-(. This seems like a case for yet another parameter to
> 'path-variable-setting-command' : 'append'. Should be easy to add.

What about prepend? Not so simple. I suggest that you make
elements enclosed in <> into environment variable substitutions.

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

>> > define it yourself (like boostbook.jam defined the 'boostbook'
>> > rule
>>
>>I will look, but as I remember everything in boostbook.jam
>>looked quite complicated.
>
>
> Yes, in particular it completely overrides V2-generated target paths 
in some
> places. The 'boostbook' rule, however, is "standard".
>
>
>>Yep, just as I recall. It's
>>completely unclear to me how one asks for a particular kind of
>>boostbook output.
>
>
> 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.
>
>
>> > ===================================================================
>> > RCS file: /cvsroot/boost/boost/tools/build/v2/tools/boostbook.jam,v
>> > retrieving revision 1.27
>> > diff -u -r1.27 boostbook.jam
>> > --- boostbook.jam 13 Nov 2004 09:29:55 -0000 1.27
>> > +++ boostbook.jam 3 Dec 2004 07:21:26 -0000
>> > @@ -32,7 +32,7 @@
>> > type.register XML : xml : : main ;
>> > type.register BOOSTBOOK : boostbook : XML ;
>> > type.register DOCBOOK : docbook : XML ;
>> > -type.register HTML : html ;
>> > +type.register HTML : html : : main ;
>>
>>Pretty simple. But isn't there something wrong, somewhere, if I
>>have to edit boostbook.jam just to add a new way to generate
>>html files via the simple mechanism?
>
>
> This frets me too. For quite some time I think that *all* new
> types should be "main". So that you decide a type and
> immediately get corresponding main rule.

Why not, anyway?

>>And ultimately, aren't there likely to be very many ways to get
>>HTML from XML? Are those generators that boostbook.jam is
>>registering going to conflict with the other ways?
>
> It's ultimately possible. For your case, however, RST -> HTML 
generator will
> only work then source is RST, so no conflicts will arise. Of course, 
defining
> several XML -> HTML generators is risky -- there should be some 
required
> properties for each generators, so that they are not tried at the 
same time.
>
>
>>Hmm, didn't work for me because paths were coming out in
>>"portable representation" -- but then, I was using path.make
>>because boostbook did the same. But I fixed that and had
>>success! Thank you!
>
>
> You're welcome!
>
>
>>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 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?

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