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

From: Andrey Melnikov (melnikov_at_[hidden])
Date: 2005-08-01 14:16:56

Alexey Pakhunov wrote:
> Andrey Melnikov wrote:
> 
>>- Recently I submitted my own bugfix-only patch (now including CVS diff) 
>>which fixes some bugs in the toolset. 
> 
> Your changes are included into this patch.
> 
>>Or to wait until first patch is 
>>reviewed and incorporated, and then change the next patch properly. I 
>>don't know which way is better.
> 
> My patch can be submitted to CVS not sooner than M11 will be released. 
> So I merge the fixes that will be checked in.
> 

Now after review by Vladimir I sent a new version of my patch. So you 
need to merge my changes again.

>>- new feature names and values will need to be carefully selected and 
>>pass a review in order to get accepted. See my discussion about 
>>precompiled headers http://article.gmane.org/gmane.comp.lib.boost.build/9602
> 
> Agree.

Can anybody help us with this review?

>>I think we should reverse engineer the PSDK setvar.cmd switches and 
>>check. I think that "platform" switch just #defines WINVER or something 
>>like this. So built-in compiler should support it too.
> 
> 
> <platform> and <arch> together affect INCLUDE, LIB, PATH, CPU, APPVER 
> and TARGETOS environment variables. The last three are really 
> interesting. They are consumed by win32.mak which sets preprocessor 
> defines and command line options in accordance to passed CPU, APPVER and 
> TARGETOS.
> 
> It seems we need to implement functionality of win32.mak as part of 
> msvc.jam.

Is our ultimate goal to make external and built-in psdk builds using the 
same set of compiler settings?

>>msvc-config is deprecated, isn't it? I think the autodetection should be 
>>built into main MSVC toolset. Or we should have -config pseudo-toolsets 
>>for other compilers too.
> 
> 
> I don't see any attempt to get rid of msvc-config.jam right now. While 
> it is still exists I gathered all detection logic there. Later it will 
> take 5 minutes to move all code from msvc-config.jam to msvc.jam.
> 
> 
Besides patch autodetection msvc-config also runs "using msvc" rule 
several times for each of the autodetected versions.

Can this functionality be built into msvc.jam? Should it?

I think we should merge registry path autodetection into msvc.jam right 
now. Msvc-config has a separate purpose.

Andrey