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
config*.cmake files are constantly getting out of sync between
each other. Besides that, the parameters are not really dependent
on a target architecture, but rather on a compiler (except *ARCH)
This approach seems to be more future-prone, and allows to see
all the options in one file (there are really not that many of them)
That way, we won't use whatever standard is the default on whatever compiler we are using.
This should also prevent using more recent features without warning.
- Updated toolchain file
- set GCC variable when using CLang in "GCC mode"
- Properly retrieve GCC support libraries
- Various flags needed to get this going
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
By sledge-hammer-reverting of
0.4.15-dev-689-g
7ffb6a09c3
and 0.4.15-dev-688-g
1234223f41
Sorry, but the negative impact for other devs and the
whole project are just unbearable.
Stuff got committed meanwhile even so I had to act.
The improvements may be reapplied later when the
negative consequences are under control.
Get rid of global properties and use a target-level properties instead
Limit temporary files by using cmake-generator expressions instead
Avoid function calls at the end configuration, use file(GENERATE) idiom instead
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
- Add ARC-emulation support for NEC PC-98 series
- Add global definition for PC-98 port into CMakeLists.txt
- Add floppy verison of freeldr.ini for PC-98 CD boot
Dynamically check for sys/types.h and pid_t in wine config.h
Use TARGET_xxx defines instead of _X86_ as this is undefined by GCC
Add some sense in include directories management by using interface
libraries
* [CMAKE] Fix for CMP0018
The new behaviour lets us explicitly disabling position independent code, avoiding the need to change undocumented variables
* LINK_DEPENDS is semicolon separated
* [CMAKE] Fix for CMP0005
it seems impossible to have cmake correct escape PROXY_CLSID_IS so move it to the header
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.
This usually happens when the build dir is a subdir of the source dir. It is now detected during runtime, using the length of the relative path from the build dir to the source dir as the length of the prefix to skip, if __FILE__ starts with a '.'.
Also fix the escaping of REACTOS_*_DIR defines. It was gracefully fixed up by CMake, but resulted in broken syntax highliting.
CORE-14839 #resolve
