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
> 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.
-- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk