Re: [jamboost] BoostBook and Boost.Build version 2

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-03-18 10:09:55

Douglas Paul Gregor wrote:

> > Chunking isn't supported with libxslt
> >
> > message, and no output, but I guess this is configuration problem on my
> > side.
>
> Perhaps you have a very old version of libxslt? I've used 1.0.19 and newer
> and have never had this problem.

Probably....

> > What's not nice currently, is relocating of manifest file. We've two
> > approaches
> >
> > 1. Don't do anything. The manifest file will be generated to
> > "bin/gcc/debug/HTML.manifest". The xsl-dir rule will find out the
> > location of manifest file and store generated files in the same location.
> > That's as clean as possible. Of course, the path "bin/gcc/debug"... is
> > wierd. But this should be fixed.
> >
> > 2. Change manifest location in another way. The 'virtual-target' class
> > has 'set-path' method. This will eliminate the need for 'common.MkDir'
> > call. It's still not quite clean, but will avoid deep directories right
> > now.
>
> I'll probably go with option #2, then. Thanks!

OK.

> > > Still no clue how to handle catalogs, unfortunately :(
> >
> > Frankly, I don't know how they should work. I'd imagine that
> > some Jamfile has
> >
> > xml-catalog boostbook : "http://nowhere.com"="/home/ghost/dtd/nowhere"
> > ;
> >
> > And that there's <xml-catalog> feature, which is honored by xslt actions.
> > On the other hand, you was trying to make the docbook rule to
> > automatically create a new target locally. I don't know what is better.
>
> I think XML catalogs will be more of an implementation detail than a real
> output. We really need just 3 paths (DocBook DTD, DocBook XSL, BoostBook
> tools), that (if available) will be in Jam variables. From those we can
> construct the catalog without the user even knowing. 

OK, since I don't have any use for xml-catalog, I've no problem if this is 
implementation detail. But I'm not sure what "Jam variables" mean. The 
general V2 approach is to avoid variables as much as possible. For
example, to configure gcc, you might say

using gcc : 3.2 g++-3.2 ;

instead of setting any variables directly. Probable this wouls be good for
BookBook as well.

> I think I've figured
> out how to do it correctly: create a file-target for the catalog with an
> action xml-catalog-action whose actualize method builds the catalog from
> the Jam variables and sets the right target properties (like null-action
> does).

Ok, let's see how this will work.

- Volodya