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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-12-03 04:42:15

On Friday 03 December 2004 12:25, David Abrahams wrote:

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

Cool. And should be easy to implement. Though, maybe, "$" is even more 
intuitive?

.setup = [ common.path-variable-setting-command
PYTHONPATH

: $(.docutils-dir) $(.docutils-dir)/extras $PYTHONPATH
: exported ] ;

Though it will exploit the fact that bjam has zero error reporting and will 
leave alone '$' that are now followed by '('.

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

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

Ok. Added to TODO.

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

> 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 :-(

- Volodya