Re: [Boost-build] Bug constructing output folder names.

From: Vladimir Prus (ghost_at_[hidden])
Date: 2008-09-02 09:43:15

On Tuesday 02 September 2008 16:48:55 Jurko Gospodnetiæ wrote:
>    Hi all.
> 
>    Below is a use case (by Juraj Ivanèiæ) causing Boost Build to 
> construct its target folder names incorrectly. It also requires a dummy 
> source file source.cpp with just 'int main() {}. To see it fail run 
> 'bjam main=off'.
> 
> #----------------
> import feature ;
> 
> feature.feature main : on off : composite propagated symmetric ;
> feature.compose <main>on  : <define>MAIN_ON ;
> feature.compose <main>off : <define>MAIN_OFF ;
> 
> feature.subfeature main off : submain : littleOff veryOff : composite 
> propagated symmetric ;
> feature.compose <main-off:submain>littleOff : <define>LITTLE_OFF ;
> feature.compose <main-off:submain>veryOff   : <define>VERY_OFF ;
> 
> exe exe : ./source.cpp : <main>on ;
> #----------------
> 
>    Many thanks if someone can look into this before me...

target.jam:common-properties2 is to blame:

rule common-properties2 ( build-request requirements )
{
    # This guarantees that default properties are present in the result, unless
    # they are overriden by some requirement. FIXME: There is possibility that
    # we have added <foo>bar, which is composite and expands to <foo2>bar2, but
    # default value of <foo2> is not bar2, in which case it is not clear what to
    # do.
    #
    build-request = [ $(build-request).add-defaults ] ;
    # Features added by 'add-default' can be composite and expand to features
    # without default values -- so they are not added yet. It could be clearer/
    # /faster to expand only newly added properties but that is not critical.
    build-request = [ $(build-request).expand ] ;

    return [ evaluate-requirements $(requirements) : $(build-request) :
        refined ] ;
}

We have <main>off in requirement, for first two statements add <main-off:submain>littleOff.
However, we also have <main>on in requirements, so the last statement strips <main>off,
but does not do anything about the subfeature. The code generating path name then
is given property set is should not have, and indulges in undefined behaviour.

I'm not sure what's the best way to fix this, especially given that the requirements
might including something like:

        <variant>debug:<main>off

I got a sneaky feeling that this problem of finding consistent set of properties should
be reduced by some math problem, presumably with a solution; but I don't know any
such problem offhand.

- Volodya