Re: [Boost-build] mysterious quickbook build error (was:: [Accumulators] Documentation )

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:

       targets.main-target-alternative
            [ 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)
                    <dependency>$(target:S=.xml)
                    : $(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.

- Volodya