From: Alexey Pakhunov (alexeypa_at_[hidden])
Date: 2005-08-05 02:51:06
Andrey Melnikov wrote:
> 1) The diff isn't against the latest CVS. I see "iff" which is already
> fixed in CVS because Vladimir has already integrated my patch there.
> 2) You didn't replace psdk with mspsdk everywhere
> 3) I dislike toolset-mspsdk: psdk, studio. For example Borland C++
> Builder isn't a "studio". I'd like to have "builtin, external" as it's
> more universal and not bound to VS. Also look in all toolsets (even in
> v1) and see how switching between different STL versions is implemented.
> I think we should implement PSDK the same way.
> 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 broken 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.
> 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.
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 would it be better to call it <msplatformsdk> instead of <mspsdk>?
It is longer but easier to understand.
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.
- 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.
Best regards/Venlig hilsen
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