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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-12-03 03:57:09

On Friday 03 December 2004 11:43, David Abrahams wrote:

> >>rule html ( target : source )
> >
> > This should be
> >
> > rule html ( target : source : properties * )
> > {
>
> Okay, I just want to point out that from reading
> http://www.boost.org/doc/html/bbv2/extending/tools.html there's
> no clue about that third parameter. In fact, unless you were
> already deeply familiar with Jam you'd have no reason to think
> that a rule called 'html' would have any significance, because
> it only prescribes writing actions. The doc should talk about
> what you might want to do in such a rule.

Noted. Will document ASAP.

> > should take care of system differences.
>
> .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.

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

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

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

- Volodya