From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2006-10-05 11:55:47
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
> 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
xml blah : blah.qbk : <dependency>blahdoc ;
> 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++ :-)
> 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
> It could be that the doxygen rule, or the xml rule, are creating targets
> with names other than those I expect.
> 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.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk