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

From: Andrey Melnikov (melnikov_at_[hidden])
Date: 2005-08-05 11:42:33

Alexey Pakhunov wrote:
> Andrey Melnikov wrote:
> 
>>4) You still have unconditionally added switches like /GS. I'd like to
>>see them as features.
> 
> 
> We have unconditional "/Zc:forScope". It is much more dangerous than 
> "/GS". Sources written for VC6 will not be compilable. Sure those 
> sources don't conform to the C++ standard but it was wide spread 
> practice. IMO we should leave /GS as it is and I have several reasons:
> 
> 1. There is no scenario when something will break because of /GS;
> 2. /GS is turned on by default in 7.1 and above;
> 3. /GS adds valuable buffer overrun detection stuff.
> 4. There is "bufferoverflowu.lib" that unconditionally linked when you 
> do amd64 build.
> 
> What do you think?
> 
> Other unconditional flags: "/wd4675" and "/Zm800" - those ones came from 
> the current msvc.jam.

Well, these are simply some things to be done. I just walked thru the 
code and noted what was wrong. I think we can leave this as is for now 
and fix in a later patch.

>>5) You still add features to MSVC toolset, and not globally. I think it 
>>isn't important for now though.
> 
> I looked into stlport.jam. It seems you are right. It is a better way to 
> implement <mspsdk> feature. It is also a much tricker way to do it. :) 
> I'll try to implement it and see how it works. BTW it is possible to 
> split the patch into two smaller pieces if it will work properly.

Yes. I think we should split it into smaller patches.

For now we have:
- x64/psdk patch
- idl patch

> Just to summarize:
> 
> You want to have two global features: <mspsdk>builtin/external and 
> <cpu-arch>i386/amd64/ia64 that will work for different toolsets. Is it 
> right?

Yes.

BTW the official name for i386 is "IA-32", the official names for Amd64 
are Amd64, EM64T and x64. i386 is often used, but it actually means 
"optimized for i386". So the names are really confusing. I think we can 
leave it as is for now.

> BTW would it be better to call it <msplatformsdk> instead of <mspsdk>? 
> It is longer but easier to understand.

We can have even <ms-platform-sdk>.

> I see a couple of side effects:

> - Global <mspsdk> will require patching each of each toolset that will 
> support PSDK based build. We will be able to discuss this as soon as I
> implement a prototype.

It won't require patches. Other toolsets will simply ignore this feature 
until they implement support for an external sdk.

> - Global <cpu-arch> will affect initialization/autodetection code for 
> sure. It is possible that simple "using msvc ;" will register 3 
> different configuration: each for one <cpu-arch>. Again we will discuss 
> it as soon as we have a prototype.

It's a complex question. I think Volodya and David will help us to 
decide correctly.

Andrey