Commit b04f3b9a (Create make rules for INTERFACE_LIBRARY
targets., 2013-08-21) extended the makefile generator to create
build targets for INTERFACE_LIBRARY targets. No other generators
were extended with this feature.
This conflicts with the feature of whitelisting of target properties
read from INTERFACE_LIBRARY targets. The INTERFACE_* properties
of the INTERFACE_LIBRARY may legitimately contain TARGET_PROPERTY
generator expressions for reading properties from the 'head target'.
The 'head target' would be the INTERFACE_LIBRARY itself when creating
the build rules for it, which means that non-whitelisted properties
would be read.
The INTERFACE_LIBRARY type does not have any LOCATION at all, so
return early from GetMappedConfig. GetMappedConfig is called from
two locations, one of which already pre-checks the INTERFACE_LIBRARY
case. Remove that pre-check and handle that case inside the method
instead.
Port upstream commit 6cf33c93 (Issue 320: Rewrite (again) to avoid
the left shift that CLang dislikes so much, 2013-12-07) into CMake.
Inspired-by: Tim Kientzle <kientzle@freebsd.org>
Xcode 5.1 output no longer puts "./" in the path to the linker output
for the CompilerId test binary. Update our regex to match the path
with or without the component.
77f3772 cmTarget: Require a compatible INTERFACE_AUTOUIC_OPTIONS from dependencies.
2e60b5f cmTarget: Report origin of COMPATIBLE_INTERFACE properties.
Revert the origin-tracking infrastructure from commit 98093c45 (QtAutoUic:
Add INTERFACE_AUTOUIC_OPTIONS target property., 2013-11-20). Use the
compatibility-tracking for compatible strings instead.
If two different dependencies require different AUTOUIC_OPTIONS,
cmake will now appropriately issue an error.
In commit ecd84147 (Fortran: Detect pointer size in gfortran on MinGW,
2011-11-29) we started testing for __SIZEOF_POINTER__ but not all GNU
Fortran compilers define this. Check also for __SIZEOF_SIZE_T__ which
at least one version of gfortran defines without also defining
__SIZEOF_POINTER__.
Since commit fd6076d0 (Tests: Pass CMAKE_MAKE_PROGRAM instead of
--build-makeprogram, 2013-11-15) the ExportImport, Fortran, and
MacRuntimePath tests use the value of CMAKE_TEST_MAKEPROGRAM as the
CMAKE_MAKE_PROGRAM for their nested projects configurations.
Teach these tests to initialize CMAKE_TEST_MAKEPROGRAM when it is
not provided, such as when building the tests manually.
259bf09 Make the cmStrictTargetComparison operate on const cmTarget*.
8cc3cdb Help: Fix up the VISIBILITY_INLINES_HIDDEN docs.
1396ab8 Don't generate self-references for system include directories.
In the code path for launching the VS IDE tools, avoid using
CMAKE_MAKE_PROGRAM. Instead use the variables CMAKE_VS_DEVENV_COMMAND,
CMAKE_VS_MSBUILD_COMMAND, and CMAKE_VS_MSDEV_COMMAND to lookup the
location of the build tool needed. Choose the proper tool based on
availability and necessity for the language (e.g. Intel Fortran must
build with devenv.com and not MSBuild.exe).
Since commit 5f5c92b9 (VS: Add internal APIs to find MSBuild,
devenv/VCExpress, and msdev, 2013-11-13) the VS generators have
known how to lookup the locations of their build tools directly.
Expose this information to CMake language code by defining new
variables to hold the paths to these tools.
Commit 66b290e7 (export(): Process the export() command at generate
time., 2012-10-06 ) refactored export() so that it could evaluate
strings at generate-time. This was intended for evaluating target
properties, but that commit also removed a check for target
existence at configure-time. Restore that check and add a test for
this case.
Stephen Kelly
Kitware Robot
Brad King
Daniele E. Domenichelli
Ted Kremenek
Clinton Stimpson
Zack Galbreath
Simon Sasburg
Nils Gladitz