Re: [Boost-build] [bbv2 test] explicit test-suite ?

From: Eric Niebler (eric_at_[hidden])
Date: 2006-10-05 13:05:42

Rene Rivera wrote:
> Eric Niebler wrote:
> 
>> If once case isn't enough, perhaps another will help. I have a jamfile 
>> for building some documentation. It has rule invocations like this:
>>
>>    doxygen blahdoc : [ glob ../../../boost/blah/*.hpp ] ;
>>
>>    xml blah : blah.qbk ;
>>
>> Somewhere inside blah.qbk, I have the line:
>>    [xinclude blahdoc.boostbook]
>>
>> which causes QuickBook to pull in the doxygen-generated reference 
>> section. This works, but there's a problem. When I touch one of the 
>> header files, the doxygen rule fires and rebuilds blahdoc.boostbook, but 
>> the blah rule, which invokes quickbook, doesn't. Because there isn't a 
>> dependency between the two rules. And I have no way of knowing how to 
>> specify the dependency.
> 
> I would say that's a bug in the quickbook build support. It should have 
> an appropriate header scanner that would catch those dependencies 
> automatically.

Not really. I could have said [xinclude myfile.xml], which could have a 
<xi:include> to include another XML file, which eventually includes 
blahdoc.boostbook. I don't want bjam chasing through XML files looking 
for dependencies -- that would be slow. And I don't want to have to tell 
bjam all the ways one xml file can include another.

>> If this were make, I'd list the one target as one of the dependencies of 
>> the other, and everything would just work. That doesn't work here. (I 
>> know because that's the first thing I tried.)
> 
> BBv2 lets you add explicit dependencies with the "dependency" feature 
> <http://engineering.meta-comm.com/resources/cs-win32_metacomm/doc/html/bbv2/advanced.html#bbv2.advanced.builtins.features>. 
> For example:
> 
> xml blah : blah.qbk : <dependency>blahdoc ;

Ah-ha! That's it, thanks.

It looks like this works because the xml rule takes a list of properties 
and does the right thing with them. If the xml rule had not taken a list 
of properties, would this have still worked? And when I specify 
dependencies like this with other rules, they might be part of a 
different argument, eg., fourth or second instead of third, right? And I 
would only know that by reading the documentation for the rule (which 
doesn't exist), right?

>> After searching, I 
>> discovered that Jam has a DEPENDS intrinsic. (Aside: IMO, the fact that 
>> Jam needs a hack like DEPENDS is indicative of the problem. Dependencies 
>> should be Jam's bread and butter.  There should be syntax for stating
>> dependencies, not a magic rule buried in some documentation. My $0.02) 
> 
> They are the bread and butter... But Jam also recognizes that it can't 
> account for everything and has access for manipulating some of the 
> target properties directly. Think of it as equivalent to being able to 
> override operators in C++ :-)

Bread and butter? It seems to me that <dependency> is just another 
feature. It hasn't been given the importance I would expect of a build tool.

>> But I couldn't make it work. If I add "DEPENDS blah : blahdoc ; " to my 
>> jamfile, blah *still* doesn't get rebuilt when blahdoc does.
> 
> That would be because the target names you use in the declarations of 
> BBv2. This difference is needed because one of the main target 
> declarations (the targets in Jamfile.v2) can generate multiple real 
> targets to account for building multiple variants, for example multiple 
> compilers.
> 
>> It could be that the doxygen rule, or the xml rule, are creating targets 
>> with names other than those I expect.
> 
> Yep :-)
> 
>> But I haven't a clue because I 
>> couldn't find where the doxygen and xml rules were documented.
> 
> Yea, we have many, many, documentation bugs :-(
> 
>> Or maybe I'm doing something silly and this problem is unrelated. But 
>> the thing is, without knowing what the targets and dependencies are, I 
>> have no way to even begin to fathom what the problem here could be. What 
>> I'm trying to do is *so simple*, and I'm completely at a loss. Help?
> 
> Hope the above helps.

It does, and thanks for taking the time.

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com