Subject: Re: [Boost-build] Target mistakenly parsed as variant
From: Vladimir Prus (ghost_at_[hidden])
Date: 2010-06-11 04:21:13
On Friday 11 June 2010 00:30:55 Anthony Foglia wrote:
> I was playing around with creating a installation rule for the
> executables we need for production, and came across an interesting bug.
> First, some backstory, we've created a production variant, to ensure we
> compile everything with static linking, as we desire.
> Now, I wrote a pair of rules:
> alias production-executable-list
> : <executables defined in jamfiles in sub directories>
> install production-executables
> : production-executable-list
> : <variant>release:<location>Release
> Then when I called
> $ bjam release production-executables
> /usr/share/boost-build/build/feature.jam:432: in validate-value-string
> from module feature
> error: "production-executables" is not a known value of feature <variant>
> error: legal values: "debug" "release" "profile" "debug-python" "production"
> If I rename the install target to "executables-for-production", then the
> corresponding bjam command works.
> I'm using Boost.Build V2 (Milestone 12), Boost.Jam version 03.1.16.
> Is bjam getting tripped by the fact that the target name starts with the
> same thing as the variant? Is this in planned behavior? Is this in the
> docs anywhere? Or is this a bug fixed in a later version?
Actually, the problem is both that target name contains dash and that the
part before dash is a name of existing property. Consider:
here gcc is name of feature and 3.4 is treated as 'subfeature'. The same happens
in your example. I am not sure there's any sensible way to disambiguate -- renaming
a target might be the best approach.
-- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build: http://boost.org/boost-build2
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