Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-10-05 13:14:06

On Thursday 05 October 2006 21:05, Eric Niebler wrote:
> 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.

Not slower than chasing though C++ header files, I think.

> 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
> > <
> >v2/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?

I'm probably getting defensive, but did you actually look at the docs? One
section, in particular, describes common syntax that a vast majority of rules

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

What would you suggest to do with <dependency>?

- Volodya

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