Boost logo

Boost-Build :

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
>>>It seems we need to implement functionality of win32.mak as part of
>>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.



Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at