search for: add_llvm_definitions

José Fonseca <jose.r.fonseca at gmail.com> writes: > Attached are two patches with MSVC build enchancements. > > They are quite trivial, but were necessary to correctly link LLVM > libraries with Mesa3D on Windows. [snip] > add_llvm_definitions( -D_SCL_SECURE_NO_DEPRECATE ) > + add_llvm_definitions( -D_SECURE_SCL=0 ) With this setting the default LLVM build becomes incompatible with libraries compiled with _SECURE_SCL=1 (which is the default setting). The right thing here is to use an option. > - add_llvm_definitions("/${...

Attached are two patches with MSVC build enchancements. They are quite trivial, but were necessary to correctly link LLVM libraries with Mesa3D on Windows. Jose -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Allow-to-build-against-static-MSVC-runtime.patch Type: text/x-patch Size: 2055 bytes Desc: not available URL:

...warning > C4099: 'llvm::Init' : type name first seen using 'class' now seen > using 'struct' [snipped some more warnings] > The rest of the project compiles clean in non-pedantic mode, quite > wonderful. :) Not so wonderful. Lots of warnings are disabled: add_llvm_definitions( -wd4146 -wd4503 -wd4996 -wd4800 -wd4244 -wd4624 ) add_llvm_definitions( -wd4355 -wd4715 -wd4180 -wd4345 -wd4224 ) add_llvm_definitions( -wd4351 ) It's very likely that some of those warnings are really useful (i.e. are hinting at bugs.) OTOH, keeping LLVM warning-free for VC++ and gcc at...

In DataTypes.h starting on line 121 are these lines: #define INT8_C(C) C #define UINT8_C(C) C #define INT16_C(C) C #define UINT16_C(C) C #define INT32_C(C) C #define UINT32_C(C) C ## U #define INT64_C(C) ((int64_t) C ## LL) #define UINT64_C(C) ((uint64_t) C ## ULL) They are conflicting with the cstdint when we have updated headers in our MSVC build. I could have sworn I talked about this

...TIONS is used via target_compile_definitions. Which, unsurprisingly, fails. Although this issue is fixed in current CMake versions (3.2+), do we really want to require these versions just to have LLVM_DEFINITIONS defined as a string instead of a list? A simple check if LLVM_DEFINITIONS is empty in add_llvm_definitions might solve the issue. -- Johannes S. Mueller-Roemer, MSc Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) Fraunhofer-Institut für Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt | Germany Tel +49 6151 155-606 | Fax +49 6151 155-139 johannes.mueller-roemer...

...NS is used via target_compile_definitions. Which, unsurprisingly, fails. Although this issue is fixed in current CMake versions (3.2+), do we really want to require these versions just to have LLVM_DEFINITIONS defined as a string instead of a list? A simple check if LLVM_DEFINITIONS is empty in add_llvm_definitions might solve the issue. -- Johannes S. Mueller-Roemer, MSc Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) Fraunhofer-Institut für Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt | Germany Tel +49 6151 155-606 | Fax +49 6151 155-139 johannes.muel...

...ild enchancements. > > They are quite trivial, but were necessary to correctly link LLVM > libraries with Mesa3D on Windows. > > Jose > > Are you volontary trying to break everyone build (just to build your own project), or have you no idea of the effect of this change: +add_llvm_definitions( -D_SECURE_SCL=0 ) While I personnaly use this flag in all my projects, it should not be silently and sneakily imposed to all llvm user. You should make it an option, and keep the default as it is currently. I.e. make this an opt-in choice. While I may seem harsh, this flag change the ABI !!!...

...his patch splits LLVM_USE_CRT into new CMake variables LLVM_USE_CRT_DEBUG, LLVM_USE_CRT_RELEASE, etc (one for each build type). It also automatically detects which CRT was already chosen by CMake's defaults in the CMAKE_CXX_FLAGS_* variables, and defaults to those values. (Before, it was using add_llvm_definitions(), which worked...somehow, but CMAKE_CXX_FLAGS_RELEASE and friends were still defining their own CRT flag. Now it edits the FLAGS variables instead.) -------------- next part -------------- A non-text attachment was scrubbed... Name: add-build-config-crt-selection-v4.patch Type: text/x-patch Size:...

...They are quite trivial, but were necessary to correctly link LLVM >> libraries with Mesa3D on Windows. >> >> Jose >> > > Are you volontary trying to break everyone build (just to build your own > project), or have you no idea of the effect of this change: > > +add_llvm_definitions( -D_SECURE_SCL=0 ) > > While I personnaly use this flag in all my projects, it should not be > silently and sneakily imposed to all llvm user. You should make it an > option, and keep the default as it is currently. I.e. make this an opt-in > choice. > > While I may seem harsh,...

....c.o -c /Users/jabbey/src/llvmCommit/lib/Support/regcomp.c cc1: error: unrecognized command line option "-Wcovered-switch-default" The problem stems from HandleLLVMOptions.cmake where a single check of the warning option is performed using check_cxx_compiler_flag, and then upon success add_llvm_definitions appends to the flag to a list consumed by both C and CXX compilers. Attached is a patch which updates HandleLLVMOptions.cmake to: - Test C and CXX compiler separately for -Wcovered-switch-default - Split SUPPORTS_COVERED_SWITCH_DEFAULT_FLAG into a C and CXX variant - Replace set( ${variable}...

...into new CMake variables > LLVM_USE_CRT_DEBUG, LLVM_USE_CRT_RELEASE, etc (one for each build > type). It also automatically detects which CRT was already chosen by > CMake's defaults in the CMAKE_CXX_FLAGS_* variables, and defaults to > those values. > > (Before, it was using add_llvm_definitions(), which worked...somehow, > but CMAKE_CXX_FLAGS_RELEASE and friends were still defining their own > CRT flag. Now it edits the FLAGS variables instead.) I'm a bit wary about this patch. So much complexity for so petty feature... Maybe the right thing is to determine the scenarios where...

...src/llvmCommit/lib/Support/regcomp.c > cc1: error: unrecognized command line option "-Wcovered-switch-default" > > The problem stems from HandleLLVMOptions.cmake where a single check of the > warning option is performed using check_cxx_compiler_flag, and then upon > success add_llvm_definitions appends to the flag to a list consumed by both > C and CXX compilers. > > Attached is a patch which updates HandleLLVMOptions.cmake to: > - Test C and CXX compiler separately for -Wcovered-switch-default > - Split SUPPORTS_COVERED_SWITCH_DEFAULT_FLAG into a C and CXX variant >...