Chris proposed on IRC to remove the Visual Studio project files and turn
CMake into the "standard" for building LLVM with VC++.
If you have strong arguments against this, please voice them.
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 otherwise a program of mine
takes 5 minutes to run (where with that safety crap disabled it takes
about 15 seconds, no joke on the times). In the VC++ projects I just
select them all, right-click, properties, C/C++, Preprocessor,
Preprocessor definitions, and add 6 definitions in there to fix it.
Although you 'can' link together parts that do not include those, and
the linker does not complain for some god forsaken reason, all your
app does then is just crash, every time, no reason as far as you can
see.
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.
OvermindDL1 <overminddl1@gmail.com> writes:
Chris proposed on IRC to remove the Visual Studio project files and turn
CMake into the "standard" for building LLVM with VC++.If you have strong arguments against this, please voice them.
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.
For C source files:
cmake -DCMAKE_C_FLAGS="-DSOME_DEF=value -DSOME_OTHER_DEF=value" path/to/llvm
For C++ source files:
cmake -DCMAKE_CXX_FLAGS="-DSOME_DEF=value -DSOME_OTHER_DEF=value" path/to/llvm
I'll add this to the docs.
Please list those defines and I will add an option for enabling them all
with a single -D cmake option.
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
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.
"Cory Nelson" <phrosty@gmail.com> writes:
OvermindDL1 <overminddl1@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.
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. 
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.
OvermindDL1 a écrit :
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.txtAnd 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
I think -DCMAKE_INSTALL_PREFIX="your/path" should work. But if you are not against gui, you may try cmakesetup (or ccmake on linux show an ncurse interface). it will show you all the available options, and allow you to change them. The option will be remenbered so you just have to do it one time, after you can just use VS.
Cédric