In commit dc6888573d (Pass EXCLUDE_FROM_ALL from directory to targets,
2019-01-15, v3.14.0-rc1~83^2) all `AddNewTarget` call sites were updated
to copy the directory-level `EXCLUDE_FROM_ALL` into the target property
of the same name, except that the one for `include_external_msproject`
was incorrectly missed. Add it now.
Furthermore, refactoring in commit b99129d2d8 (ENH: some code cleanup,
2007-03-12, v2.6.0~2020) accidentally set the `EXCLUDE_FROM_ALL` target
property of `include_external_msproject`-generated targets to `FALSE`
instead of simply leaving it unset. This was not necessary but had no
effect until the above commit gave it a meaning. Drop that.
Fixes: #18986
The original warning pre-dates support for install components.
There are now legitimate scenarios where an install(TARGETS)
command may list a target that is excluded from all, e.g.
hierarchical projects that will never install the component such a
target belongs to.
Fixes: #18938
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
This adds the cmQtAutoGenGlobalInitializer::GetExecutableTestOutput method
which caches the output of the called executable and returns the cached value
on any subsequent call.
VS 2019 does not default to the 8.1 SDK as VS 2017 and VS 2015 did.
When `CMAKE_SYSTEM_VERSION` is 8.1 or lower, select the 8.1 SDK
explicitly.
Fixes: #18927
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.
The quoting added by commit 8c5221fb1f (try_compile: Preserve special
characters in COMPILE_DEFINITIONS, 2019-01-21, v3.14.0-rc1~108^2~3)
broke the case that the `COMPILE_DEFINITIONS` value contains a `;`.
Without the quoting the `;` would be generated literally in an unquoted
argument in the test `CMakeLists.txt` file and would then be expanded.
With quoting the `;` is preserved, which is not the old behavior.
Fix this by expanding the `;`-list ahead of time. Add test cases for
behavior with both `#` and `;`.
This was noticed with the PGI compiler where we set
`CMAKE_CXX*_STANDARD_COMPILE_OPTION` to values like `--c++17;-A`. The
symptom had also been observed while preparing commit ef8f237686
(ParseImplicitIncludeInfo: add SunPro Fortran and PGI compiler, Cray
fix, 2019-01-29, v3.14.0-rc1~26^2~2) but was not recognized at the time
as a regression. Revert the workaround added by that commit.
Fixes: #18919
The naming convention for submodule files varies across compilers. Add
a table to the compiler information modules and thread the information
through to the Fortran module dependency parser. Fill out the table for
compiler ids known to support Fortran submodules.
Fixes: #18746
The check added by commit 0a29a31161 (VS2017: Verify Windows 8.1 SDK
before using it, 2017-04-25, v3.8.1~2^2) used the wrong path to
`windows.h` within the SDK, leading to it never being detected.
Fixes: #18923
The `cmsys/Enconding.h` include had a typo in its surrounding ifdef,
possibly causing a missing function declaration (`cmsysEncoding_DupToWide`).
As this is C code, this resulted in the code compiling, but with a truncated
return value, possibly causing crashes.
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
Since commit dc6888573d (Pass EXCLUDE_FROM_ALL from directory to
targets, 2019-01-15, v3.14.0-rc1~83^2) we automatically forward the
`EXCLUDE_FROM_ALL` to targets as they are created. This regressed
support for interface libraries on which the property is not allowed.
Skip forwarding the `EXCLUDE_FROM_ALL` property for interface libraries.
It is not needed on them because they do not participate in the
generated build system anyway.
Fixes: #18896
a28caabf45 Autogen: AUTOMOC support for files with the same name but different extensions
1f802295f2 Autogen: Extend the SameName test with same name but different extension files
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2920
`CUDA_RESOLVE_DEVICE_SYMBOLS` can be used with shared, module, and
executable target types. This relaxation is to allow for better
interoperability with linkers that automatically do CUDA device symbol
resolution and have no way to disable it.
This adds support for AUTOMOC to moc header files with the same but different
extensions (e.g `obj.h`, `obj.hpp`, `obj.hxx`). If a moc file would appear
multiple times in `mocs_compilation.cpp`, a number suffix is appended
to the name to make it unique.
Closes#14489
b6cf086267 Autogen: Iterate over makefile sources only once
ed0fa784eb cmSystemTools: Let `GetFileFormat` accept a `std::stding const&`
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2909
