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
> : $(.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
.setup = [ common.path-variable-setting-command
: $(.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:
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
> 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 :-(
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