Since commit 1c2d031cbd (Add -E cmake_llvm_rc to preprocess files for
llvm-rc, 2020-01-14, v3.17.0-rc1~24^2) with llvm-rc we explicitly
preprocess RC source files and then compile separately without -I flags.
This broke cases where the RC source references data files adjacent to
itself or in the include path.
This change adds the expansion of the include paths when calling the
llvm-rc in order for the resource files to be picked up correctly by
llvm-rc. Since the RC compiled file is first preprocessed, the file
being compiled by llvm-rc resides in the build directory. In order for
llvm-rc to find the resource data specified relative to the .rc file
being compiled, the source file path is preppended in the include list
so that the original source path takes priority over all the other
includes paths specified.
A space was added in the CMAKE_INCLUDE_FLAG_RC to make the include
directive work properly for llvm-rc. Checks on the rc.exe showed that
the syntax change doesn't affect it's proper operation.
Fixes: #20529
2af18704fd Merge branch 'backport-3.16-link-libs-config-case'
3f976bf201 target_link_libraries: Fix regression in case of $<CONFIG> genex
5a95b5e091 target_link_libraries: Fix regression in case of $<CONFIG> genex
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4544
Since commit b8626261e9 (Precompile headers: Add methods to generate PCH
sources, 2019-07-13, v3.16.0-rc1~182^2~4) we look up source files for a
target using an upper-case configuration even though an original-case
name is sufficient. Since commit 36ded610af (PCH: Generate sources
during Compute step, 2019-10-05, v3.16.0-rc1~2^2) the source file lookup
is the first time we compute many on-demand structures that depend on
the configuration name. This caused the `$<CONFIG>` generator
expression to evaluate to the upper-case configuration name in some
cases where we used original-case before.
Fix this by switching the source file lookup to the original-case config
name. Add a test covering the symptom that led to the discovery of this
problem.
Fixes: #20517
Since commit d1976cd1f2 (CTest: Fix timeout when grandchild keeps pipes
open, 2020-01-13, v3.17.0-rc1~169^2) we no longer hang, but the test
duration we report after the timeout is the amount of time the immediate
child ran before exiting. Fix the logic to instead report the actual
amount of time we spent monitoring the test before the timeout.
Fixes: #20509
CMake 3.16 and below allow multiple `export()` calls with the same output
file even without using `APPEND`. The implementation worked by accident
by leaking memory. Refactoring in commit 5444a8095d (cmGlobalGenerator:
modernize memrory managemenbt, 2019-12-29, v3.17.0-rc1~239^2) cleaned up
that memory leak and converted it to a use-after-free instead.
The problem is caused by using the `cmGlobalGenerator::BuildExportSets`
map to own `cmExportBuildFileGenerator` instances. It can own only
one instance per output FILE name at a time, so repeating use of the
same file now frees the old `cmExportBuildFileGenerator` instance
and leaves the pointer in the `cmMakefile::ExportBuildFileGenerators`
vector dangling. Move ownership of the instances into `cmMakefile`'s
vector since its entries are not replaced on a repeat output FILE.
In future work we should introduce a policy to error out on this case.
For now simply fix the use-after-free to restore CMake <= 3.16 behavior.
Fixes: #20469
In commit 3dab4682f6 (FindPython: reduces consumption of resources,
2020-02-10, v3.17.0-rc1~11^2) we accidentally broke the python
executable version validation when the "LOCATION" strategy is used
with the plain `FindPython` module. Fix the logic and add test
cases covering those combinations.
Fixes: #20465
The properties added by commit 4a62e3d97c (macOS: Add
OSX_COMPATIBILITY_VERSION and OSX_CURRENT_VERSION properties,
2020-01-24, v3.17.0-rc1~80^2~1) are general-purpose for all platforms
using Mach-O formats and not just on OS X. Rename them accordingly.
The properties are new to the CMake 3.17 release so we can rename
them without compatibility concerns.
Fixes: #20442
If cross-config mode is used, and a target depends on another target
as well as a custom command, we don't want the custom command to also
depend on the depended target, as that would build targets unnecessarily.
Fix this behavior.
We may want to enable these variables later on with specific
semantics. To avoid breaking backwards compatibility, make it an
error to use them for now.
Also rename `..._DEFAULT_BUILD_FILE_CONFIG` to `..._DEFAULT_BUILD_TYPE`.
These name changes make the variables meaningful for future use by other
generators.
95dbcf0598 Tests: fix RunCMake.Make test when run on systems with non-english locale
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4389
818ec34bdd file: GLOB_RECURSE VerifyGlobs.cmake should have CMP0009 set to new
b620dc566d file: Fix GLOB_RECURSE LIST_DIRECTORIES documentation regarding CMP0009
715f90bdd9 Tests: Perform minor cleanups in RunCMake.file test
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kyle Edwards <kyle.edwards@kitware.com>
Merge-request: !4342
Prior to this fix, CMAKE_NMC_DEFAULT_CONFIGS would inherit "all" from
the union of CMAKE_NMC_DEFAULT_BUILD_FILE_CONFIG and
CMAKE_NMC_CROSS_CONFIGS. This is inconsistent with the behavior of the
"all" target signifying CMAKE_NMC_CROSS_CONFIGS. Update "all" in
CMAKE_NMC_DEFAULT_CONFIGS to inherit only from CMAKE_NMC_CROSS_CONFIGS.
In certain cases, rebuilds with CMake using the CONFIGURE_DEPENDS flag
with GLOB_RECURSE could result in a reconfigure loop due to CMP0009 not
being propogated to the generated VerifyGlobs.cmake script.
During the inital configuration phase, RecurseThroughSymlinksOn() is
called for recursive glob operations either by having the CMP0009 status
not set to NEW or by explicitly providing the FOLLOW_SYMLINKS flag. At
the end when the VerifyGlobs script is created, the FOLLOW_SYMLINKS flag
is written according to the final resolved form through a call to
GetRecurseThroughSymlinks(). Thus, setting CMP0009 to NEW in the
generated file is safe and allows correct behavior whether or not the
end user sets the policy status to NEW or OLD.
In commit 9fc20a4f3e (install: Add sane set of defaults for DESTINATION
and file type parameters, 2018-11-02, v3.14.0-rc1~410^2~1), a regression
was introduced, in which an `install(TARGETS)` with a
RUNTIME/LIBRARY/ARCHIVE DESTINATION but no PUBLIC_HEADER/PRIVATE_HEADER
DESTINATION would then install the headers. The old behavior did not do
this. Restore the old behavior.
Fixes: #20326
Populate `CMAKE_Swift_IMPLICIT_INCLUDE_DIRECTORIES` with the macOS SDK's
include directory so that we filter such implicit directories out of
Swift targets.
Fixes: #19845
Fix an issue where CMAKE_NMC_DEFAULT_BUILD_FILE_CONFIG is specified
and CMAKE_NMC_CROSS_CONFIGS is not, which results in a false error
with CMAKE_NMC_DEFAULT_CONFIGS.
