* [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
This became a requirement, following a previous CMake update.
Otherwise the built EXEs would not export their intended functions.
Addendum to commit d8e92b5a (see PR #1335)
CORE-15406
[LOADCONFIG] The GCC rant had nothing to do with GCC, but everything with CMake...
[SPOOLSV] Add the missing exported stubs.
- 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
This option is only useful for the i386 architecture and breaks ARM builds.
Reviewed-by: Victor Perevertkin <victor.perevertkin@reactos.org>
Reviewed-by: Stanislav Motylkov <x86corez@gmail.com>
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Some compilers call it 'arm64', while others prefer 'aarch64'. It's a big mess,
thanks Arm Ltd...
Reviewed-by: Stanislav Motylkov <x86corez@gmail.com>
Reviewed-by: Serge Gautherie <reactos-git_serge_171003@gautherie.fr>
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
list() functions expects numerical indices for modification operations
and silently converts everything else to a number (old behaviour).
CMake 3.21 now checks this and throws a warning
The upstream driver is not maintained and the file system itself
is in a semi-abandoned state.
Originally imported at 3a3ef631d1
The driver is written by Lee Jae-Hong, updated by Bo Brantén.
ReactOS porting made by Peter Hater and Pierre Schweitzer.
Follow updates at http://www.acc.umu.se/~bosse/
FS Recognizer code is left to keep the FS support as an
installable driver.
CORE-11040
The upstream driver is not maintained and the file system itself
is in a semi-abandoned state.
Originally imported at e308102f4a
The driver is written by Mark W Piper, updated by Bo Brantén.
ReactOS porting made by Peter Hater and Pierre Schweitzer.
Follow updates at http://www.acc.umu.se/~bosse/
FS Recognizer code is left to keep the FS support as an
installable driver.
CORE-11005
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)
