Boost logo

Boost-Build :

From: Eric Niebler (eric_at_[hidden])
Date: 2008-07-23 14:11:03


The problem described below is now on the critical path for 1.36. Steven
Watanabe attached a patch to the bug report 3 months ago:

http://svn.boost.org/trac/boost/ticket/1584

Can somebody pls verify the patch and commit ASAP?

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
==Original Message==
Vladimir Prus wrote:
> 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

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