From: Vladimir Prus (vladimir_at_[hidden])
Date: 2008-01-24 07:11:32
Jurko GospodnetiÄ wrote:
> Hi Eric.
>> Not an expert, but I'll try to take a whack at it later today (in
>> about 8 hours). Never used docbook/quickbook/boostbook though and don't
>> really understand what and how that stuff works so bare with me. :-)
> Sorry, once I wrote this real-life work stepped in and been doing
> 16-hour work-days since then. :-(
> Will try to look at this today...
What's happening, it seems is that doxygen.jam has this:
[ new alias-target-class $(target) : $(project)
: [ targets.main-target-requirements $(requirements)
: $(project) ]
: [ targets.main-target-default-build $(default-build) : $(project) ]
: [ targets.main-target-usage-requirements $(usage-requirements)
: $(project) ]
So it tries to add a dependency property to usage requirements. The dependecy
properties are tricky -- they are specified using target ids, but when
a target is build, dependency property are converted to contain the virtual
targets created from corresponding target ids. When dependency property is
used in usage requirements, we return a dependency property that already has
virtual target as value, and when other targets try to treat that value
as target id, we go boom.
The possible solutions are:
- Don't convert dependency property values to target in usage requirements.
The problem here is that 'some_target' might be valid in usage requirements
in one project, but won't be valid in some other project far far away.
- Disallow dependency properties in usage requirements. In fact, I think
using <dependency> requirement, not usage requirement will work just fine
in most cases -- except here. Since alias does not produces any targets,
<dependency> requirement will get ignored.
I think I'd need to think more about this.
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