GCC has some functions, variables & type attributes which can be used as aliases
for some of the SAL annotations. Although it's not as rich & precise, it's still useful
since we actually enable -Werror on GCC builds whereas we don't use such an option
on MSVC builds.
For now, _Must_inspect_result_ is aliased to warn_result_unused attribute.
This speeds up boot a bit and also decreases binary size.
- Introduce a new CMake define ISAPNP_ENABLE that defined only in x86 platform
when ISA PnP is supported.
Also, put include directory next to the library and use
target_include_directories(.. INTERFACE ..) to get this right.
This is because :
- Having includes & implementation in two different places buggers me
- This makes sure that there is no "if it compiles everything is fine" behaviour from anyone
because now even static libraries need it for GCC amd64 build
Also add __USE_PSEH2__ define for the non SEH-aware compilers out there and use it in a few headers
where we define macros involving __try
\#pragma REACTOS SEH(except)
\#pragma REACTOS SEH(finally)
What it does is counting the number of SEH __try blocks and emit the proper assembly statements at function prologue
It also checks for mixing C++ & SEH exception handling, which wouldn't work
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)
- Updated toolchain file
- set GCC variable when using CLang in "GCC mode"
- Properly retrieve GCC support libraries
- Various flags needed to get this going
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
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
This version (after .rsrc) works different than the
proper version I used for 0.4.12 (after .reloc).
Inserting after .rsrc is actually not correct, but Thomas believes it can
be used as a temporary trick to avoid random memory corruption upon
relocations of the kernel, caused by ROSBE-154.
I follow his advice, although when judging from practical tests only:
as long as we limit this script to NTOSKRNL like I do for releases
there have no negative consequences been observed in real life yet
even with the proper version of 0.4.12.
Up to now those problems have only been observed when used for drivers
MODULE TYPE sdk/cmake/gcc.cmake as well, like
it was tried for a moment in master 0.4.13-dev-609-g
c4d8e2a6e9
Using for drivers immediately did lead to BSODs like CORE-16183 and therefore was
mitigated in master by total disabling of the scripts for both,
kernel and drivers in
0.4.13-dev-621-g
36e9a6f8dd
To allow installing DVDWritenow without BSOD,
we need the script at least for ntoskrnl!
I committed this patch (after .rsrc) already into 0.4.13RC and 0.4.14RC.
