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

From: Andrey Melnikov (melnikov_at_[hidden])
Date: 2005-08-02 05:17:27

Alexey Pakhunov wrote:
> Andrey Melnikov wrote:
> 
>>><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?
>>
> 
> win32.mak deals with a quite reasonable subset of settings:
> - defines: WINVER, _WINNT, _WIN95, _WIN32_WINNT, _WIN32_WINDOWS, 
> _WIN32_IE, _X86_, _IA64_, _AMD64_, WIN64, _WIN64, WIN32, _WIN32
> - compiler flags: -W3, -W4, -Wp64, -GS
> - midl flags
> - default libraries
> 
> It is logical to use at least some of them since we've got <platform> 
> and <arch> settings.

BB doesn't use win32.mak even with <mspsdk>builtin, does it?

We only need to run setenv.cmd to set variables used by compiler itself. 
So we actually only need INCLUDE, LIB and PATH environment variables.

So for BB it doesn't matter if we use /XP32, /SRV32 or /2000 switch, 
because compiler settings will indeed be the same. So we can always pass 
the same /XP32 /DEBUG values there, can't we?

If we want _WINNT etc to be defined, then we'll have to define it 
ourselves using <platform> feature. So the feature will work for all 
configurations and compiler versions, not only for PSDK builds.

Also, unlike <cpu_architecture> feature, <platform> isn't a feature of 
compiler. It doesn't configure the compiler, it configures the used 
Platform SDK. So it's better to make <platform> a subfeature of 
<mspsdk>. Something like mspsdk-platform.

This name will also give users the idea that thay almost never need to 
change the feature's value. Most people don't care about this and always 
use the latest platform setting in PSDK. So BB shouldn't force them to 
think about its value in simple cases.

Probably we'll only need to add bufferoverflowU.lib when buffer security 
checks are turned on and support for turning security on and off.

We have a lot of switches not supported by msvc.jam now. So I think we 
can safely postpone <mspsdk-platform> for now. It isn't that important.

Andrey