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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-08-12 07:50:58

On Friday 05 August 2005 01:20, Andrey Melnikov wrote:

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

Architecture should be a feature, as soon as it's possible to build for 
several architecture at the same time (which I think is possible). The same 
test can be applied to mpsdk -- if you can build with two different values at 
the same time (or at the same machine), then it should be a feature.

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

Right, so architechture should be full-blown feature.

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

I think Dave had his reason for making linker name customizable. Dave?

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

Yes, and that's what the patch does -- it removed the "version" parameter 
altogether, as well as the "command" parameter. 

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

Since I don't know what's mpsdk, you have to answer this yourself, using the 
"simultanious build with different values" test.

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

I hope the current discussion on initialization syntax will settle soon, so 
we'll be able to do something.

- Volodya

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