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
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
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