headers
John Maddock | 15 Nov 13:35

Inserting an extra stage into the BoostBook toolchain?

OK, I have a very primitive automatic indexer, that accepts Docbook XML as 
input along with a concordance/script file and outputs another Docbook XML 
file with index entries inserted.  It would speed up development a great 
deal if I could insert this tool into the regular quickbook/boostbook build 
process, anyone have any pointers on how to achieve this?  And yes, I've 
looked at the extender manual, but can't see at present how to modify an 
existing tool chain...

Many thanks, John. 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Permalink | Reply |
headers
Alexander Sack | 15 Nov 17:42

Re: Inserting an extra stage into the BoostBook toolchain?

On Sat, Nov 15, 2008 at 7:35 AM, John Maddock <john <at> johnmaddock.co.uk> wrote:
> OK, I have a very primitive automatic indexer, that accepts Docbook XML as
> input along with a concordance/script file and outputs another Docbook XML
> file with index entries inserted.  It would speed up development a great
> deal if I could insert this tool into the regular quickbook/boostbook build
> process, anyone have any pointers on how to achieve this?  And yes, I've
> looked at the extender manual, but can't see at present how to modify an
> existing tool chain...

John, I'm not familiar with Docbook but from your description above I
see that you have some tool that takes XML and script input and pops
out another XML file.  Is there any reason why you don't use a notfile
or make rule to do the dirty work?  Generators are typically used to
to allow Boost.Build to manage generated source codes files which
isn't really the case here.  You can write a custom generator that
handles non-source related files (there are several examples in
$BOOST_BUILD_PATH/tools/*.jam) but this is way more involved.

Again, have you seen this part of the doc?

http://www.boost.org/doc/tools/build/doc/html/bbv2/builtins/raw.html

You could write a custom rule that would just to the dirty work for you...

-aps
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Permalink | Reply |
headers
Vladimir Prus | 15 Nov 18:02
Favicon

Re: Inserting an extra stage into the BoostBook toolchain?

Alexander Sack wrote:

> On Sat, Nov 15, 2008 at 7:35 AM, John Maddock <john <at> johnmaddock.co.uk> wrote:
>> OK, I have a very primitive automatic indexer, that accepts Docbook XML as
>> input along with a concordance/script file and outputs another Docbook XML
>> file with index entries inserted.  It would speed up development a great
>> deal if I could insert this tool into the regular quickbook/boostbook build
>> process, anyone have any pointers on how to achieve this?  And yes, I've
>> looked at the extender manual, but can't see at present how to modify an
>> existing tool chain...
> 
> John, I'm not familiar with Docbook but from your description above I
> see that you have some tool that takes XML and script input and pops
> out another XML file.  Is there any reason why you don't use a notfile
> or make rule to do the dirty work?  Generators are typically used to
> to allow Boost.Build to manage generated source codes files which
> isn't really the case here.  You can write a custom generator that
> handles non-source related files (there are several examples in
> $BOOST_BUILD_PATH/tools/*.jam) but this is way more involved.
> 
> Again, have you seen this part of the doc?
> 
> http://www.boost.org/doc/tools/build/doc/html/bbv2/builtins/raw.html
> 
> You could write a custom rule that would just to the dirty work for you...

This is probably not very attactive. We want 

        boostbook a : a.xml ;
(Continue reading)

Permalink | Reply |
headers
John Maddock | 15 Nov 19:18

Re: Inserting an extra stage into the BoostBooktoolchain?

Vladimir Prus wrote:
>>> You could write a custom rule that would just to the dirty work for
>>> you...
>>
>> This is probably not very attactive. We want
>>
>>        boostbook a : a.xml ;
>>
>> to work. John, where exactly this new tool should be inserted, and
>> should it
>> always be run, or under some conditions?

Well... in an ideal world:

* It would run on the Docbook XML, just before the Docbook XSL stylesheets 
get involved, but after the Boostbook->Docbook transform, at a pinch it 
might work on Boostbook input, but I'm less certain on that.
* It would be run only when requested (ie pay for what you use).
* It has some options that need to be passed from the Jamfile down to the 
tool on the command line.
* Ideally all without messing about with the current toolchain too much.
* I can rig the tool the either generate a new XML file, or over-write the 
original whichever is easier (the latter might be harder to debug though).

As you can see, I'm not asking for much ;-)

Many thanks, John. 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
(Continue reading)

Permalink | Reply |

Gmane