Re: [BBv2] quickbook.jam and boostbook question

From: Joao Abecasis (jpabecasis_at_[hidden])
Date: 2005-01-31 06:33:18

Hi!

Vladimir Prus wrote:
> On Friday 28 January 2005 16:43, Joao Abecasis wrote:
>>Since no one has objected and since quickbook now lives in the tools
>>directory I guess that somehow grants me the right to add the toolset to
>>BB... ;)
> 
> 
> Sure. But please provide more complete comment at the top of the file than:
> 
> # Provides quickbook rule to handle generation of documentation from QuickBook 
> # Sources.
> # Interesting stuff is in boostbook...
> 
> At least say where QuickBook HTML docs can be found. Preferrable both URL and 
> Boost tree location. A sentence describing what QuickBook will also help.

Noted. I'll document more thoroughly before committing to CVS!

> Also, 
> 
> # Make boostbook rule visible as quickbook.quickbook
> IMPORT boostbook : boostbook : $(__name__) : quickbook ;
> # And then as global quickbook
> IMPORT $(__name__) : quickbook : : quickbook ;
> 
> seems like a mistake. It makes global "quickbook" rule do exactly the same as 
> "boostbook" rule. I've just did some testing and was very confused by this 
> behaviour.

Well, the idea was to create an "alias" to boostbook, so that the user
would be forced to initialize the quickbook toolset...

Anyway, I see that it may be confusing and error prone to have two
names for the same rule. I'll drop this. It also becomes unnecessary if 
the quickbook executable is being automatically generated.

>>I tried to define only the QUICKBOOK -> BOOSTBOOK generator, figuring BB
>>would see BOOSTBOOK as an XML type anyway. But, it turns out it doesn't
>>work that way (attached are the error messages I got trying this approach).
> 
> 
> This looks like a bug! When we're trying to create XML type (that what 
> boostbook's generator want), we don't consider generators which produce types 
> derived from XML -- in this case Boostbook. Some hacking is in order, but in 
> the meantime, you'd have to create XML type.

Thanks for looking into this. I've tried XML before and it works fine 
for me.

>>>>>Are there other alternatives I am missing? How bad could it be to define
>>>>>the generator as QUICKBOOK -> XML?
>>>
>>>I don't think that's all that bad. I suggested another variant only
>>>because it's consistent with doxygen.jam.
>>
>>I can settle for QUICKBOOK -> XML. Anyway, I'll give doxygen.jam a
>>closer look.
> 
> 
> I've just tried locally with QUICKBOOK -> XML and it seems to work.

Yes. That was one of the two possibilities that worked for me too ;)

>>BTW, is there a way for the build process to generate the quickbook
>>executable once with a single compiler and always use that executable,
>>regardless of the number of compiler toolsets available?
> 
> 
> In some form it's possible. If you want quickbook to be automatically built 
> the first time I add .qbk file in the list of sources, right? The attached 
> works for me, but needs to avoid hardcoding the path to quickbook.

Thanks for that! This is what I wanted. Borrowing some ideas from 
boostbook.jam I've managed to search for the quickbook sources, thus 
avoiding the hardcoded path.

One last thing. With your code, the quickbook executable is taken as a 
target to compile if it hasn't been yet. How would I provide a pre-built 
executable. Say, the user already has it somewhere in the path:

using quickbook : /path/to/quickbook ;

How do I set a default value for the <quickbook-binary> feature and 
avoid having the executable built?

I tried to use feature.set-default but I got an error stating 
/path/to/quickbook is not an allowed value...

Once again, thank you very much for your help and for the great tool
you're developing!

Best regards,

João