Re: [jamboost][BBv2][msvc] amd64, ia64 and some other features

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-08-04 03:35:18

On Wednesday 03 August 2005 22:52, Andrey Melnikov wrote:
> Vladimir Prus wrote:
> > On Tuesday 02 August 2005 22:40, Andrey Melnikov wrote:
> >>3) I think it's a bad idea to specify default values for features in
> >>init rule. I think feature.set-default rule should be run instead, or
> >>there should be another similar mechanism to do this.
> >>
> >>I also see similar fragments in old msvc.jam:
> >>
> >> linker = [ get-values <linker> : $(options) ] ;
> >> linker ?= link ;
> >>
> >>I think Vladimir Prus can help us here because I'm not so fluent in BB
> >>internals. Vladimir, is this a recommended practice or it's a legacy
> >> code?
> >
> > The story is that it's not a real feature -- it just uses feature-like
> > syntax to pass named parameters to the 'init' rule, so you need to apply
> > defaults here.
>
> Why it isn't a real feature? What are the differences between real and
> not real features?

I mean that <linker> above is not a feature at all. You can't specify it
in Jamfile, or on command line. Why? Because we haven't had a use case for
such flexibility -- specifying linker on the command like is funky.

> Personally I don't think that <linker> for msvc is useful. Is it
> actually possible to use Intel linker with MSVC just by specifying it in
> site-config or user-config? What are the use-cases for this in other
> toolsets?
>
> > We though that even better syntax will use the '=' sign:
> >
> > using msvc : : linker=some_linker ;
>
> Well, if now it's
>
> using msvc : : <linker>some_linker ;
>
> then it's fine. I think we should have consistent syntax everywhere. On
> bjam command line name=value is fine because it help us to avoid to deal
> shell argument escaping. But in Jamfiles I'd like to see this syntax.

Dave and I though that eventually it's best to move to "feature=value" syntax
everywhere, including Jamfiles.

> Here's a code snippet from his patch:
>
> +feature.subfeature toolset msvc : version
> + : 8.0 7.1 7.0 6.0
> + : propagated
> + ;
> +
> +feature.subfeature toolset msvc : platform
> + : win2k3 winxp win2k
> + : propagated
> + ;
> +
> +feature.subfeature toolset msvc : arch
> + : i386 amd64 ia64
> + : propagated
> + ;
> +
> +rule init (
> + options *
> + )

Ouch! This changes the syntax of msvc declaration, and so it must
be separately documented, which is not good!

> +{
> + #
> + # Get unique toolset id: version, platform, arch and sdk.
> + #
> +
> + version = [ get-values <version> : $(options) ] ;
> + version ?= 8.0 ;
> +
> + platform = [ get-values <platform> : $(options) ] ;
> + platform ?= win2k3 ;
> +
> + arch = [ get-values <arch> : $(options) ] ;
> + arch ?= i386 ;
> +
> + sdk = [ get-values <sdk> : $(options) ] ;
> + sdk ?= studio ;
> +
> + local condition =
> + [ common.check-init-parameters msvc :
> + version $(version) :
> + platform $(platform) :
> + arch $(arch) :
> + sdk $(sdk)
> + ] ;
>
> Is this a good idea to set default values for features this way? 

Again, here's it's not a feature, it's just named parameter. I don't think 
this approach is right. It means that after

using msvc ;

user will get target path in the form msvc-8.0-win2k3-i386-studio. This 
exactly what common.check-init-parameters tries to prevent. Consider a easier
case:

rule init ( version ......... )
{
...
local condition = 
[ common.check-init-parameters msvc : version $(version) ;

If the version is empty, then no "version" subfeature is used at all. Target 
path is "msvc". If version is not empty, then "version" subfeature will be 
created, target path will be "8.0". If you try to initialize first without 
version, and then with version, you get an error.

As result, you don't get new path element unless you specify version. I think
the same approach should be applied for new features. So, the

sdk ?= studio ;

and the like should be remove, IMO.

> Can you 
> comment on the whole patch?

Ah.. the problem is that the patch is very large. I'll try to split it
into separate parts and comment on them.

- Volodya

-- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2