* [CMAKE] msvc.cmake: Remove redundant '/Gy'
Function-level-Linking '/Gy' is already enabled unconditionally
at line 26. So no need to enable it here another time.
Makes the differences between the multiple OPTIMIZE-levels more obvious.
* [CMAKE] msvc.cmake: Fix typo in comment
- Add some of the missing CMake adjustments to continue the configure and compile process with ARM64 MSVC
- Created quick stubs for the functions in SDK needed to finish the configuration process
- Put in an ARM64 option for spec2def
CORE-17518 CORE-17615
Having conditional statements with CMAKE_BUILD_TYPE is an antipattern
See https://stackoverflow.com/questions/66079007/having-conditional-statements-on-build-type-variable-a-good-design
We use both single- and multi-config generators (Ninja and VS), so we
can't really rely on CMAKE_BUILD_TYPE, because it's not always set.
This commit alters some conditional flags to use <$CONFIG:...>
generator expression, but is still not complete. Also, our default
optimization level (4) now has what was always a de-facto flags
in favor of add_compile_options and the like with generator expressions
Also take this as an opportunity to remove the C++11 standard hack, GCC 8 now defaults to C++14
Instead of messing with global variables and the like, we introduce two target properties:
- WITH_CXX_EXCEPTIONS: if you want to use C++ exceptions
- WITH_CXX_RTTI: if you need RTTI in your module
You can use the newly introduced set_target_cpp_properties function, with WITH_EXCEPTIONS and WITH_RTTI arguments
We also introduce two libraries :
- cpprt: for C++ runtime routines
- cppstl: for the C++ standard template library
NB: On GCC, this requires to create imported libraries with the related built-in libraries:libsupc++, limingwex, libstdc++
Finally, we manage the relevant flags with the ad-hoc generator expressions
So, if you don't need exceptions, nor RTTI, nor use any runtime at all: you simply have nothing else to do than add your C++ file to your module
Since binutils can not add this, we re-introduce pefixup.
It searches for the exported symbol '_load_config_used',
and uses that to fill out the LOAD_CONFIG directory in the PE header
Remove RTC switch from configure.cmd, now MSVC runtime checks are
supposed to be enabled/disabled via CMake define (-DRUNTIME_CHECKS=1)
Prepare for adding more dynamic analysis options
For MSVC, marking the section as discardable will do this automatically.
For GCC, we use a linker script that places it after the .reloc section
(which should be the last "real" section, check ld --verbose output for the
default linker script).
This fixes what seems to be a regression from r55835 (!).
Up to CMake 3.3 LINK_DEPENDS was ignored in non-Makefile generators. See also http://www.cmake.org/pipermail/cmake/2010-May/037206.html. Since CMake 3.4 it is no longer ignored, but requires CMP0005 policy to be set to NEW and it requires a full path which was already correctly used on GCC, but not on MSVC builds.
- C4311: pointer truncation from '<pointer>' to '<integer>'
- C4312: conversion from '<integer>' to '<pointer>' of greater size
- C4133: incompatible types - from '<x> *' to '<y> *'
- C4028: formal parameter different from declaration
There is no need to compile our DLLs as shared libraries since we are
managing symbols exports and imports through spec files.
On my system, this reduces the configure-time by a factor of two.
MSBuild, via the VS IDE, uses response files when calling CL or LINK.
We cannot specify a custom response file on the linker command-line,
since specifying response files from within response files is forbidden.
We therefore have to pre-process, at configuration time, the linker
script so as to retrieve the custom linker options to be appended
to the linker command-line.
