On AIX, symbols in executables must be exported in order to be visible
to modules (plugins) they load via `dlopen`. Prior to policy `CMP0065`,
CMake linked all executables with flags to export symbols, but the NEW
behavior for that policy is to do so only for executables that have the
`ENABLE_EXPORTS` target property set. In both cases, CMake has always
used the AIX linker option `-bexpall` option to export symbols from
executables.
This has worked fairly well with the XL compiler, but with the GNU
compiler it works only for C ABI symbols. The reason is that `-bexpall`
does not export symbols starting in `_` but the GNU C++ ABI mangles all
symbols with a leading `_`. Therefore we have only supported C ABI
plugins with the GNU compiler on AIX. Some projects have tried to work
around this by replacing `-bexpall` with `-bexpfull`, but the latter
often exports symbols that we do not want exported.
Avoid using `-bexpall` for executables by instead using by our own
internal `ExportImportList` script to compute symbol export lists from
the object files to be linked into an executable. Pass the explicitly
computed export list to the AIX linker's `-bE:...` option. We already
do this for shared object exports.
Issue: #19163
An old workaround for `std::allocator_traits<>::value_type` lints from
IWYU on `std::vector<>` usage breaks IWYU's handling of `<memory>`.
Convert the workaround to use the same approach we already use for a
workaround of `std::__decay_and_strip<>::::__type` lints. Then update
the `<memory>` inclusions to follow the now-correct IWYU lints.
This changes the behaviour of the generators to use a per-language
library search path flag. This is needed for multi-language projects
with different compilers (e.g. cl + gfortran). Since the adjusted
variable has been part of the user settings, we control this based on a
policy.
Fixes: #19307
Avoid the use of `CMAKE_{EXE,SHARED}_LINKER_FLAGS` when linking with the
Swift language. This required hoisting the executable flags of
`CMAKE_CREATE_WIN32_EXE`, `CMAKE_CREATE_CONSOLE_EXE`, and
`CMAKE_EXE_EXPORTS_*_FLAG` earlier to avoid a second clause which checks
the language. This allows for mixed-language Swift projects to properly
link on Windows.
Fixes#19298
Entries of the `CPATH` environment variable are implicitly searched as
include directories by some C/C++ compilers. Since commit 5990ecb741
(Compute implicit include directories from compiler output, 2018-12-07,
v3.14.0-rc1~108^2) these entries are detected by CMake and included in
the `CMAKE_{C,CXX}_IMPLICIT_INCLUDE_DIRECTORIES` variables.
However, we should not exclude them from explicit specification via `-I`
or particularly `-isystem` because they are meant as user-specified
include directories that can be re-ordered without breaking compiler
builtin headers. In particular, we need explicit requests via
`include_directories` with the `SYSTEM` option to result in `-isystem`
so that third-party headers do not produce warnings.
Co-Author: Ben Boeckel <ben.boeckel@kitware.com>
Fixes: #19291
Replace our hard-coded defaults for `/MD` and `/MDd` with a first-class
abstraction to select the runtime library from an enumeration of logical
names. We've long hesitated to do this because the idea of "runtime
library selection" 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 flags 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 CMP0091 to provide
compatibility.
Fixes: #19108
The IPO flag logic was added to `AddLanguageFlags` based on my advice.
However, this method should really only be about `CMAKE_<LANG>_FLAGS*`
variables. Move the IPO logic out to its call sites.
a8b7cbb787 Autogen: Do not treat hard-coded -I/usr/include exclusion as implicit include
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3159
The `cmLocalGenerator::GetIncludeDirectoriesImplicit` method is called
by `cmQtAutoGenInitializer` to get the compiler's list of implicit
include directories. Since commit 557b2d6e65 (Fix regression in
-I/usr/include exclusion logic, 2019-02-13, v3.14.0-rc2~6^2~2) the
method hard-codes exclusion of `/usr/include` for historical reasons.
However, it should not be reported as a real implicit include directory
unless the compiler really has it.
Refactor the logic to distinguish the hard-coded exclusion of
`/usr/include` from the real list of implicit include directories.
Fixes: #19100
3dc81a48ff Fortran: Do not suppress explicit use of implicit include directories
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Michael Hirsch, Ph.D. <michael@scivision.co>
Merge-request: !2994
Since commit 2e91627dea (ParseImplicitIncludeInfo: add Fortran implicit
include handling, 2019-01-25, v3.14.0-rc1~73^2) we actually populate
`CMAKE_Fortran_IMPLICIT_INCLUDE_DIRECTORIES` for the first time. This
value may be useful to project code to pass to other tooling that wants
to preprocess the way Fortran does, so we should compute the value.
However, compilers like `gfortran` do not actually search their own
implicit include directories for `.mod` files. The directories must be
passed via `-I` in order for `.mod` files in them to be found.
Since Fortran has no standard library header files that we need to avoid
overriding, it is safe to *not* filter out implicit include directories
from those passed explicitly via `-I` options. Skip this filtering so
that include directories specified by project code to find `.mod` files
will be searched by the compiler even if they happen to be implicitly
searched by the preprocessor.
Fixes: #18914
890bae524c Do not explicitly report "standard" include directories as implicit
5c171ca898 Restore unconditional use of "standard" include directories
9502276f82 Prefix implicit include directories with sysroot on construction
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2981
In commit 1293ed8507 (ParseImplicitIncludeInfo: keep implicit incl.
consistent when rerunning cmake, 2019-01-30, v3.14.0-rc1~26^2) we did
not account for `CMAKE_<LANG>_STANDARD_INCLUDE_DIRECTORIES`. This
variable lets platform modules or toolchain files specify directories
that are to be explicitly passed as standard include directories. These
include directories are used by the test project from which we extract
implicit include directories so they appear in the parsed results
whether or not the compiler really considers them implicit. Exclude
these entries from the computed implicit include directories since they
are not actually implied by the compiler when we invoke it with
"standard" include directories passed explicitly.
Instead teach the build system generators to treat the "standard"
directories as implicit for purposes of excluding them from appearing
earlier in the compiler command line due to `include_directories` and
`target_include_directories` calls.
Issue: #18936, #18944
`CMAKE_<LANG>_STANDARD_INCLUDE_DIRECTORIES` is meant to unconditionally
add explicitly specified include directories to compile lines. In
commit 5f34bdc7f9 (cmLocalGenerator: Refactor
`GetIncludeDirectoriesImplicit` method, 2019-01-25, v3.14.0-rc1~65^2~1)
a condition was accidentally added to exclude implicit include
directories. Drop that condition.
Fixes: #18936
Since commit 7cd65c97fa (Add CMAKE_SYSROOT variable to set --sysroot
when cross compiling., 2013-04-13, v3.0.0-rc1~342^2) we have prefixed
the value of `CMAKE_SYSROOT` to implicit include directories. This was
done because we hard-coded `/usr/include` as an implicit include
directory without accounting for the sysroot. Instead we should prefix
the hard-coded paths when they are constructed. Update the
`Platform/UnixPaths` module to do this as `Platform/Darwin` already
does.
Since commit 5990ecb741 (Compute implicit include directories from
compiler output, 2018-12-07, v3.14.0-rc1~108^2) the values of the
`CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES` variables are computed from
a real compiler invocation so they already account for the sysroot
prefix. In commit 6fc3382944 (Update logic for sysroot in detected
implicit include directories, 2019-02-13, v3.14.0-rc2~6^2) we attempted
to apply the prefix conditionally, but that is incorrect because the
compiler's real implicit include directories are not all under the
sysroot. Instead assume that all implicit include directories in
`CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES` already have the sysroot
prefix if needed. Code that constructs the value must be responsible
for that because it is the only place that knows.
6fc3382944 Update logic for sysroot in detected implicit include directories
2ad14ef4ea cmAlgorithms: Add cmHasPrefix to match existing cmHasSuffix
557b2d6e65 Fix regression in -I/usr/include exclusion logic
017598a444 macOS: Fix addition of <sdk>/usr/include to default implicit include dirs
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2957
Since commit 5990ecb741 (Compute implicit include directories from
compiler output, 2018-12-07, v3.14.0-rc1~108^2) the values of the
`CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES` variables are computed from
a real compiler invocation. In this case the paths under the sysroot
should already have the sysroot prefix so we should no longer have to
add the sysroot prefix. However, it is also possible for project code
to add its own paths to `CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES`
without the sysroot prefix and expect the historical addition of the
sysroot prefix to be preserved.
Try to account for both cases by conditionally adding the sysroot prefix
on implicit include directories that do not already have it.
The change in commit 15ad830062 (Refactor exclusion of -I/usr/include to
avoid per-language values, 2019-01-21, v3.14.0-rc1~108^2~4) caused the
exclusion to apply to Fortran, but it was only meant for C, CXX, and
CUDA. The purpose of the change was to prepare for the value of
`CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES` to be computed from the
actual compiler instead of hard-coded. We need to preserve exclusion of
`-I/usr/include` if the compiler has any implicit include directory that
looks intended to replace it, e.g. `<sdk>/usr/include` on macOS.
Fixes: #18914
01b2d6ab74 Modernize: Use ranged for-loops when possible
15bdbec017 cmAlgorithms: Make cmRange advance/retreat safe for rvalues
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Daniel Pfeifer <daniel@pfeifer-mail.de>
Merge-request: !2901
Use a dedicated `std::set` for implicit include directories instead
of (ab)using the emitted variable. This in combination with lambdas
makes it easier to comprehend which paths are emitted.
For the implicit include directories we used to omit the
`CMAKE_SYSROOT_COMPILE`/`CMAKE_SYSROOT` prefix. This has been changed and
the implicit paths are returned prefixed. Implicit include directory returning
is only ever used by QtAutoGen which requires prefixed paths. QtAutoGen passes
the (implicit) include paths to the `moc` which isn't aware of
`CMAKE_SYSROOT_COMPILE`/`CMAKE_SYSROOT`.
This patch strips the `stripImplicitDirs` and `appendAllImplicitDirs`
parameters from the `cmLocalGenerator::GetIncludeDirectories` method and makes
it a wrapper into the new `cmLocalGenerator::GetIncludeDirectoriesImplicit`
method. `cmLocalGenerator::GetIncludeDirectoriesImplicit` is the renamed old
implementation of `cmLocalGenerator::GetIncludeDirectories` and still
accepts `stripImplicitDirs` and `appendAllImplicitDirs`.
The motivation is that there's only *one* case where
`cmLocalGenerator::GetIncludeDirectories` is called with the
`stripImplicitDirs` parameter being `false` (QtAutoGen), but many other places
where it is called using the `true` default value.
QtAutoGen is modified to use `cmLocalGenerator::GetIncludeDirectoriesImplicit`
directly. In two use cases of `cmLocalGenerator::GetIncludeDirectories`
the manually set `true` value for `stripImplicitDirs` is removed.
5990ecb741 Compute implicit include directories from compiler output
d751d2d2ed CMakeDetermineCompilerABI: set locale to C for try_compile()
c765ae495a CMakeDetermineCompilerABI: pass verbose flag during compilation
8c5221fb1f try_compile: Preserve special characters in COMPILE_DEFINITIONS
15ad830062 Refactor exclusion of -I/usr/include to avoid per-language values
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2716
Add a `CMAKE_PLATFORM_IMPLICIT_INCLUDE_DIRECTORIES` to contain the
hard-coded list of paths to be excluded from `-I` arguments so that the
values remain excluded even if the per-language
`CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES` variants change.
This is needed to preserve our historical exclusion of `-I/usr/include`
even when it is not a real implicit include directory. A policy may be
needed to remove it later.
