This variable has been provided since commit 746906242d (Android: Detect
NDK version number, 2021-02-26, v3.20.0-rc3~1^2~3) when using CMake's
NDK support or the modern NDK toolchain file. Since commit 005e2cdfb0
(Android: Do not use gold for ndk >= r22, 2021-02-26, v3.20.0-rc3~1^2)
we need the value in our compiler/platform information files, so provide
it when using the NDK legacy toolchain file too.
Revert commit 1c86e397fe (Android/Clang: Tolerate undefined
CMAKE_ANDROID_NDK_VERSION, 2022-09-16, v3.25.0-rc1~118^2) since the
variable should now always be defined.
Issue: #21772Fixes: #24386
This add correct Open Watcom support for 16-bit Windows 3.x.
It replace existing strange mixture with WIN32 stuff which implement 16-bit Windows target partially as part of WIN32 stuff.
Now pre-defined OS ID Windows3x is used instead of confusing WIN32.
It support properly 16-bit and 32-bit application for 16-bit Windows host.
32-bit applications are build with OW WIN386 extender.
It is used similar as for other platforms by set CMAKE_SYSTEM_NAME=Windows3x and CMAKE_SYSTEM_PROCESSOR=I86 for 16-bit application or CMAKE_SYSTEM_PROCESSOR=x86 for 32-bit WIN386 extender application running on 16-bit Windows 3.x.
CMAKE_SYSTEM_NAME=Windows is used only for WIN32 applications.
Add setup of system include directories to language related macro to remove extra lines for C and CXX.
System include directories are always same for both languages (they are defined per platform).
Prior to CMake 2.8.4 (released in 2011), we defined `WIN32` on CYGWIN.
That was removed, but an undocumented `CMAKE_LEGACY_CYGWIN_WIN32`
compatibility mode was left to help projects transition. Only projects
that do not require at least 2.8.4 as their minimum CMake version need
the compatibility mode. We've also long warned about projects that do
not require at least 2.8.12, so it is now reasonable to remove the
legacy compatibility mode.
Replace old-style `file(APPEND .../CMake{Output,Error}.log)` logging
with calls to `message(CONFIGURE_LOG)` to record the steps in the
`CMakeConfigureLog.yaml` configure log instead.
Issue: #23200
The fix in commit e9755bc7c1 (MinGW: Restore using windres when
toolchain-prefixed name is not available, 2022-08-15, v3.24.1~4^2)
incorrectly listed two entries in `CMAKE_RC_COMPILER_INIT`, which is
only meant to have one value. Revise the logic to support multiple
platform-specific names for the Windows Resource Compiler while still
only using one name as the fallback when it is not found.
Fixes: #24190
Issue: #23841
Since commit 62cd3904bf (variable: Set LINUX variable on Linux target
systems, 2022-08-10, v3.25.0-rc1~320^2), the `Platform/Android` module
inherits the `LINUX` variable setting from `Platform/Linux`. While
Android may use a Linux kernel, `CMAKE_SYSTEM_NAME` is not `Linux`, and
the platform does not follow conventions of most Linux distributions.
Fixes: #24196
Revert commit be848a71b0 (MSVC: Teach find_library to consider the
'libfoo.a' naming convention, 2022-09-19, v3.25.0-rc1~111^2). When
targeting the MSVC ABI, this causes GNU-ABI libraries to be found in
cases they were not previously, and broke existing builds. Revert the
change pending further discussion on how to handle the motivating use
case.
Issue: #23975Fixes: #24168
Don't initialize the other CMAKE_<LANG>_COMPILER_PREDEFINES_COMMAND
variables.
The only language variant that is used is
CMAKE_CXX_COMPILER_PREDEFINES_COMMAND, and the other language variants
contained invalid, namely C++-specific commands.
Fixes: #23968
When cross-compiling for Android, the library path suffixes `/<number>/`
refer to API level specific platform libraries instead of architecture
bitness. Disable path suffix use under NDK to avoid incorrect inclusion
of API level specific libraries below the targeted API level.
Fixes: #23830
Serenity's LibDl was merged into LibC to simplify the build and port
infrastructure [1]. Set `CMAKE_DL_LIBS` to the empty string to match
what other platforms do. Update the platform module added by
commit 45ca894164 (SerenityOS: Add Platform module, 2022-01-02,
v3.25.0-rc1~635^2).
[1] https://github.com/SerenityOS/serenity/pull/14854
Issue: #23589
Add a platform module for using clang for HIP on windows, based on the
CXX module.
HIP language on windows works without this, but mixing with MSVC
produces catastrofical results.
Add the same restriction with HIP as C and C++ had prior:
Either none are compiled with MSVC or all are.
clang-cl support for HIP does not work yet: it needs more work in both
hip-lang-config.cmake and cmake itself.
a858466aac MSVC: Add test for debug information format
0e96a20478 MSVC: Add abstraction for debug information format
d4c8111da4 Clang/Windows: Clarify name of internal runtime library flags variables
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7606
Replace our hard-coded default for `/Zi` with a first-class abstraction
to select the debug information format an enumeration of logical
names. We've long hesitated to do this because the idea of "debug
information format" touches on related concepts on several platforms.
Avoid that scope creep by simply defining an abstraction that applies
only when targeting the MSVC ABI on Windows.
Removing the old default flag requires a policy because existing
projects may rely on string processing to edit them and choose a
runtime library under the old behavior. Add policy CMP0141 to
provide compatibility.
Fixes: #10189
Intel classic compilers generate erroneous dependencies when gcc style
is used with paths containing spaces. So, fall back to the old way to
generate dependencies by using option /showIncludes.
Fixes: #23948
a20d7a9707 BSD: Set *BSD variables when targeting a *BSD system
2ae42d0aa3 kFreeBSD: Do not unset LINUX variable
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7573
e9755bc7c1 MinGW: Restore using windres when toolchain-prefixed name is not available
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7574
Since commit 55ba10dcfd (MSYS/MinGW Makefiles: Simplify selection of
windres as Resource Compiler, 2022-05-26, v3.24.0-rc1~82^2) the `MinGW
Makefiles` and `MSYS Makefiles` generators no longer specify the plain
`windres` name for the MinGW resource compiler. Instead, the name is
specified in our MinGW platform information module. After the change in
commit af4adf6aa9 (MinGW: Fix default windres selection when
cross-compiling, 2020-03-25, v3.18.0-rc1~492^2), when cross-compiling,
we only specify the toolchain-prefixed name of the tool, which may not
be available in all environments.
If the toolchain-prefixed name is not available, fall back to the plain
`windres` name. We already use this approach for other binutils.
Fixes: #23841
Replicate and adapt Linux IPO options for Intel for IntelLLVM compilers
on Linux and Windows.
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
When linking an executable, DLL, or static library, the compiler sometimes
needs to see the linking options. Typically `<FLAGS>` is not passed
for linking, because some of the options are only used for compilation.
Previously, `<LINK_FLAGS>` was passed after the `/link` flag because
the compiler did not understand some of the linking options.
This change wraps the initial linker options borrowed from Windows-MSVC
individually, so that they are passed directly to the linker.
This change is helpful both for interprocedural optimization, which needs
to pass `-Qipo` to the compiler at link time, and for SYCL which needs
to pass `-fsycl` and possibly other options to the compiler at link time.
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
When interprocedural analysis is enabled on the IBMClang family of
compilers (via the `-flto` option) then the resulting object files
contain LLVM IR rather than XCOFF objects[1].
ExportImportList needs to detect LLVM IR objects and use the
`ibm-llvm-nm` tool that ships with the compiler to create the extract
the defined symbols.
Without this change, such objects result in an error message from
`dump` and no symbols being exported from the object file.
[1]: https://www.ibm.com/docs/en/openxl-c-and-cpp-aix/17.1.0?topic=compatibility-link-time-optimization-lto
Since LCC 1.26.03, compiler developers decided to rename
liblfortran to libgfortran (internal reference: mcstbug#131633),
and despite it's stated that "-llfortran will be automatically
treated as -lgfortran", it actually does not work (and there's
even no symlinks like liblfortran.* -> libgfortran.*); so we
have to explicitly choose which library we have to link in.
Fixes: #23646
Add an initial Platform module for SerenityOS [1]. This module is a mix
of the platform module currently used to build the Serenity Kernel and
Userspace applications and libraries, and the platform module included
in the CMake Port [2] which still has some work to do on the system
before its other patches could be considered for upstream.
As such, the platform module is currently only useful when used with a
suitably patched GCC or LLVM cross-compiler toolchain.
[1] https://github.com/SerenityOS/serenity
[2] https://github.com/SerenityOS/serenity/tree/master/Ports/cmake/patches
Issue: #23589
