|
Boost Testing : |
From: David Abrahams (dave_at_[hidden])
Date: 2007-03-26 18:07:08
on Mon Mar 26 2007, Roland Schwarz <roland.schwarz-AT-chello.at> wrote:
> David Abrahams wrote:
>> 1. Is it possible that the version or the toolset name contains a dash
>> (it always used to be possible to make a toolset name containing a
>> dash, c.f. intel-win)
>
> True.
>
>> 2. If one substring is numeric, does that necessarily constitute the
>> version number?
>
> No. As I understand it: It depends, on the ability to deduce the feature
> from an implicit value (the version identifier in this case).
>
>
>> 3. When invoking the toolset's "init" rule to configure it, what
>> should I do with any additional dash-separated substrings?
>
> You would need to deduce the features from the values and then
> put it into the using rule. (Which clearly is infeasible.)
>
> So the only workable solution I can see at the moment:
>
> 1) scan off the toolset property from the string, by making use
> of the feature module.
No, that doesn't work for autoconfiguration, because IIUC the values
of <toolset> are created by calls to "using toolsetname". This
feature is supposed to work without any setup of xxx-config.jam.
> 2) Knowing the toolset try to infer the version from the string
> by making use of feature expansion again.
That won't work either, because as you noted earlier, the feature
module depends on having had the allowed subfeature values specified
already.
> 3) If we were not able to consume the whole string
"consume the whole string?"
> _and_ need to autoconfigure,
How do we know if we "need to autoconfigure?"
> print a warning and let the
> toolset take care of autoconfiguration.
"let the toolset take care of autoconfiguration?"
> If this does not work we
> will get an error in a later stage. If it works we are fine.
>
> 4) In the other case we did not need to autoconfig, and passing
> toolset version to "using" will select the correct toolchain
> from user-config.jam, or we were able to consume the whole
> string and there are no additional subfeatures the user
> intended to pass on.
>
> I certainly would like to assist if you need a helping hand,
> but unfortunately I think am still not knowledgeable enough to
> understand the boost.build code sufficiently good.
Rene is right; we need to decide on stricter conventions for toolset,
etc., naming
-- Dave Abrahams Boost Consulting www.boost-consulting.com