Boost logo

Boost-Build :

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

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at