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

From: Andrey Melnikov (melnikov_at_[hidden])
Date: 2005-08-04 16:20:19

Vladimir Prus wrote:
> 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. 

What about CPU architecture and mspsdk to be used? How in your opinion 
they should be implemented? As features or as named parameters?

I should be able to build variants for several CPUs from command line. 
It's also reasonable to be able to specify CPU requirements in Jamfiles, 
for example if user always wants to build both 32 and 64-bit versions. 
The use case is the same like for simultaneous building of debug and 
release libraries.

> 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?

If you don't see any use cases, can we just hardcode the linker 
parameter then and get rid of this ugly code?

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

ic now. We could also use name=>value syntax as it's used to define 
associative arrays in PHP and Perl. I think => is more precise than = 
and less mysterious than <name>value. But = sounds well to me, too.

>>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!

I think we'll need to support x64 for all compilers that support it. So 
we should change the syntax anyways. Of course we shouldn't break 
backward compatibility without good reasons.

>>+{
>>+ #
>>+ # 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 removed, IMO.

My question was: Should mspsdk be a real feature?

>>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.

I run exactly into the same trouble.

The patch is so large because all autodetection code was moved to 
msvc-config.jam and because changes from my recent patch weren't merged.

I hope Aleksey will create a new version of the patch very soon, and 
we'll be able to comment.

Let's focus on msvc.jam and msvc-config first then.

Andrey