Re: [Boost-testing] error: "8.3/runtime" is not a known subfeature value of <toolset>cw

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2006-12-15 12:15:30

David Abrahams writes:
> Aleksey Gurtovoy <agurtovoy_at_[hidden]> writes:
> 
> > Vladimir Prus writes:
> >> Aleksey Gurtovoy wrote:
> >> > Don't we want this working before we release?
> >> 
> >> Why would we? "toolset=" autoconfiguration is a way to help first time
> >> users.
> >
> > It's also the way the bjam invocation is documented in the new Getting
> > Started guide and Boost.Build v2 documentation
> > (http://boost.org/boost-build2/doc/html/bbv2/advanced/invocation.html).
> 
> Nothing in the getting started guide says that you can pass
> "/-features" along with the toolset when using --toolset=....  

Right, but what I'm saying is that "--toolset=" is an advertized way
of passing, well, a toolset to bjam, and it's not obvious from
Boost.Build v2 docs that a more complex toolset specification
_requires_ a different form of invocation. Nor is it intuitive,
especially considering that

    Vladimir Prus writes:
    > Omitting "toolset=" is just for convenience.

> Of course, I'm happy to add that feature.

Could you, please?

> But when Volodya suggests that the "--toolset" change be reverted, I
> think he's referring to the change in the testing script that made
> it start using the --toolset= feature, not to removing the feature
> itself.

I understood that, and while I'll have no problems doing that for 1.34
if needed, I'm strongly opposite to settling on the status quo as a
permanent state. We've been trying hard to make becoming a Boost
regression runner as painless as possible, and complicating the
initial setup of 'regression.py' -- which is what switching back to
the "--toolset"-less form equals to -- is a step in the opposite
direction.

[...]

> > Thank you. What I was trying to say, though, that at the moment the
> > "cw-8.3/runtime-link=static" toolset specification doesn't work,
> > '--toolset=' option present or not.
> 
> Oh, that's another problem.

Until that's resolved, I see no point in reverting the change in
question: for all we know, the resolution might involve removing the
offending piece from the command line and adding some equivalent of it
to the toolset specification in 'user-config.jam', thus making it a
non-issue.

> 
> >> >>         2. Using autoconfiguration for regression tests might be a
> >> >>         bad idea in general.
> >> > 
> >> > Why?
> >> 
> >> Because instead of having a single file that's says that versions
> >> you have configured and how,
> >
> > Sorry, I don't see why I should be required to write a file that says
> >
> >     using msvc : 7.1 ;
> >
> > instead of simply being able to request the same in the command line.
> 
> One danger is that the autoconfiguration will pick up a different
> version of the compiler and call it 7.1 (e.g. if all the usual
> autoconfiguration methods fail and it falls back to looking for the
> tools that are in the PATH), and we'll get strange results in our test
> matrix.  

Why would we want this behavior in the first place (i.e. why not fail
if 7.1 is not found)?

> That danger is somewhat reduced if people have to explicitly
> think about specifying configuration.

I don't think that the amount of thought that goes into writing

   python regression.py --runner=<My runner id> --toolsets=msvc-7.1

is any different than the amount of thought that goes into writing

   using msvc : 7.1 ;

   python regression.py --runner=<My runner id> --toolsets=msvc-7.1

-- 
Aleksey Gurtovoy
MetaCommunications Engineering