llvm dev - Nov 2008 - [LLVMdev] Removal of Visual Studio project files.

"Cory Nelson" <phrosty at gmail.com> writes:
> On Mon, Nov 24, 2008 at 8:18 PM, Óscar Fuentes <ofv at wanadoo.es>
wrote:
>> OvermindDL1 <overminddl1 at gmail.com> writes:
>>> As long as instructions are supplied on how to pass in user defined
>>> macros to the build system.  I have to turn off a lot of the extra
>>> safety crap that VC2k5 and higher added
>> [snip]
>>> I am sure I am not the only one that does that, so supplying such
>>> instructions for how to add in your own preprocessor definitions
would
>>> be great.
>>
[snip]
> He's talking about how VC++ deprecated (with warnings) many C/C++
> functions (like strcpy, sprintf, std::copy, etc.) that a dumb
> developer could get exploited with.  Turn them off with these:
>
> _CRT_SECURE_NO_WARNINGS // C deprecation
> _SCL_SECURE_NO_WARNINGS // C++ deprecation
>
Those and others already are defined by default:

if( MSVC )
  add_definitions( -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS )
  add_definitions( -D_SCL_SECURE_NO_WARNINGS -DCRT_NONSTDC_NO_WARNINGS )
  add_definitions( -D_SCL_SECURE_NO_DEPRECATE )
  add_definitions( -wd4146 -wd4503 -wd4996 -wd4800 -wd4244 -wd4624 )
  add_definitions( -wd4355 -wd4715 )
endif( MSVC )
> In addition to those, for Release builds I recommend disabling the
> "secure" stdlib features which does bounds checking and slows
down a
> lot of good code:
>
> _SECURE_SCL=0 // slow secure stdlib.
This isn't, but adding an option for just one define does not save any
work.

-- 
Oscar

On Mon, Nov 24, 2008 at 10:13 PM, Óscar Fuentes <ofv at wanadoo.es>
wrote:
> /* snip */
Thanks so much for that information.  :)

For note, this is my usual line I add to the end of my preprocessor
definitions in *every* single project I ever open now (thanks to some
very bad memories associated with not having them).

;_CRT_NONSTDC_NO_DEPRECATE;_CRT_SECURE_NO_DEPRECATE;_SECURE_SCL=0;_SCL_SECURE_NO_DEPRECATE;_HAS_ITERATOR_DEBUGGING=0

Most of those will be obvious, but as stated, both _SECURE_SCL and
_HAS_ITERATOR_DEBUGGING (especially this last one, you can 'sometimes'
get by with linking on just _SECURE_SCL, but not with
_HAS_ITERATOR_DEBUGGING for some forsaken reason) will cause very
nasty and horrible crashes if a program is linked together where one
part defines those and another part does not and there is *any*
sharing of anything in the stl between modules (yes, even
std::basic_string).  The crashes are near impossible to diagnose if
you do not know about these ahead of time.

As such, with any library I distribute, one of the build options
always includes one that defines these as well.  I follow a boost
style naming convention, so for a project like myLib a full build
would create files like these:
myLib_32dyp.lib
myLib_32dy.lib
myLib_32dsp.lib
myLib_32ds.lib
myLib_32ryp.lib
myLib_32ry.lib
myLib_32rsp.lib
myLib_32rs.lib
myLib_32rdyp.lib
myLib_32rdy.lib
myLib_32rdsp.lib
myLib_32rds.lib

Where 32 means it is 32-bit, d means it is a debug build, r means it
is a release build, r and d together mean it is a release build with
debug info, y is a dynamic library (uses a corresponding dll file), s
is a static lib, p means it has all my preprocessor defines from
above, no p means it does not.  A setup like this in cmake would be
perfect I would have to say (well, minus the dynamic libs since they
are not well supported).

I really wish I could have stuck with VS2k3, regardless of the
(surprisingly) few complience issues it had, it just ran as you would
expect, no hidden gotchas and other crap like these definitions.

And good god yes, when using the stl in some cases, without all of the
above, it adds so freaking much bound checking code that, quite
literally, there was a ~170 to 1 ratio of lines of assembly of bound
checking related code compared to *my* code.  Putting the defines in
shrunk it a great deal, and my code ran in over 20 times faster.  If I
wanted bounds checking I would use Java, I need speed and I right now
I would love to use some very colorful metaphors about the person at
Microsoft who initially came up with these retarded things.  It would
not be so bad if the linker identified the incompatible code and
choked like normal, but since it does not... I really hate that
person... I lost so much time and sanity...

Nice, very well done on the CMake build.  This command worked perfectly:

cmake -G "Visual Studio 8 2005"
-DCMAKE_CXX_FLAGS="-D_CRT_NONSTDC_NO_DEPRECATE
-D_CRT_SECURE_NO_DEPRECATE -D_SECURE_SCL=0 -D_SCL_SECURE_NO_DEPRECATE
-D_HAS_ITERATOR_DEBUGGING=0" ..\trunk > ..\build_log.txt

And for the actual build, went very well.  The INSTALL was much
project was better then I was expecting (although did not install to a
place I wanted it to, I guess that can be changed with another option
passed to the above command-line call).  No errors in the build, and
the only real warnings I saw were just things like signed/unsigned
mismatch and using struct before but using class now and other such
things (that should be fixed regardless, but no biggies).  The
projects worked correctly, and I never knew LLVM came with a BF
compiler, may have to play around with that to see how well the LLVM
version works. :P

As a heavy VS user, I am up for removing the project files considering
how well this went and how well designed he made it.