When writing export files, correctly encode property values that contain
characters special to the CMake language parser. We must ensure that
they parse correctly when loaded on the consuming side.
Reported-by: Dan Liew <dan@su-root.co.uk>
When the policy was added by commit 783bce29 (Export: Disallow exported
interface includes in src/build tree, 2014-03-31) it accidentally left a
code path that would warn when the include dir is in the install tree
but *not* in the source or build tree. Fix that.
Allow directories in the source tree or build tree only if the
install tree is a subdirectory of the source tree or build tree,
as appropriate.
Re-use the test files in the RunCMake.include_directories test
to run in multiple scenarios. Bump the required CMake version
in the test to 3.0 to ensure that the new policy warnings are
emitted correctly.
Use the clang RemoveCStrCalls tool to automatically migrate the
code. This was only run on linux, so does not have any positive or
negative effect on other platforms.
Most callers already have a std::string, on which they called c_str() to pass it
into these methods, which internally converted it back to std::string. Pass a
std::string directly to these methods now, avoiding all these conversions.
Those methods that only pass in a const char* will get the conversion to
std::string now only once.
5838aba Export: Report error on relative include with genex.
7a3e45b Export: Prefix relative items with genexes in INSTALL_INTERFACE.
f088a32 Export: Process INSTALL_INTERFACE in INCLUDES DESTINATION.
9eedc85 Export: Process relative includes after genex evaluation.
80790f3 Export: Test existing behavior of exporting includes with genexes.
38afc82 target_include_directories: Allow relative path with genex
Diagnostics which check the sanity of exported include paths
previously skipped over any path containing a generator expression.
Introduce a policy to issue an error message in such cases.
The export files created in the OLD behavior are not usable, because
they contain relative paths or paths to the source or build location
which are not suitable for use on installation. CMake will report an
error on import.
Code such as
install(TARGETS ...
INCLUDES DESTINATION $<INSTALL_INTERFACE:include>
)
should behave as if the INSTALL_INTERFACE wrapper were not present.
In code such as
install(TARGETS ...
INCLUDES DESTINATION $<FOO>include
)
the generator expressions are evaluated at generate-time. Delay
determining whether each entry is a relative path until after
the generator expressions are evaluated. Such relative paths
are based relative to the CMAKE_INSTALL_PREFIX.
As an INTERFACE_LIBRARY has no direct link dependencies, we can
short-circuit in cmGeneratorExpressionEvaluator and
in cmGlobalGenerator::CheckLocalGenerators.
As they do not generate any output directly, any generate- or install-
related code acn also be short-circuited. Many of the local generators
already do this.
Because only INTERFACE related properties make sense on INTERFACE_LIBRARY
targets, avoid setting other properties, for example via defaults.
Resolve conflict in Source/cmTarget.cxx by integrating the changes to
the internal copy constructor from both sides. Also resolve a logical
conflict by dropping the special case for INTERFACE_LIBRARY targets.
Since cmTarget::SetMakefile already forces CMP0022 to NEW for such
targets we need no special handling.
Resolve conflict in Source/cmTargetLinkLibrariesCommand.h by dropping
the documentation change. We will make the same change in the new
location of the same documentation in a separate commit.
Resolve conflicts in
Tests/RunCMake/CMP0022/CMP0022-WARN-empty-old-stderr.txt
Tests/RunCMake/CMP0022/RunCMakeTest.cmake
by taking the side from the 'policy-CMP0022-fixes' branch.
When cmExportFileGenerator::SetImportLinkInterface exports the old
LINK_INTERFACE_LIBRARIES property values it skips doing so for
non-linkable targets because target->GetLinkInterface returns NULL for
such targets.
Since cmExportFileGenerator::PopulateInterfaceLinkLibrariesProperty
looks at the INTERFACE_LINK_LIBRARIES property directly instead of using
the computed link interface, teach it to skip exporting the property if
target->IsLinkable returns false.
Extend the RunCMake.CMP0022 test with a case covering this. Simply
export an executable target that links to a library that is not
exported.
The CMP0022 NEW behavior is that the INTERFACE_LINK_LIBRARIES property
exactly defines the link interface. The plain target_link_libraries
signature says linking is transitive by default, so it should populate
the property.
Teach the target_link_libraries plain signature to populate the
INTERFACE_LINK_LIBRARIES regardless of the CMP0022 setting. Refactor
the cmTarget::ComputeLinkInterface checks that warn when the policy is
not set to compare the new property to either the explicitly set old
link interface properties or the link implementation fallback for all
linkable target types, not just static libraries.
This fixes a regression in 2.8.12.0 that caused target_link_libraries to
not implement transitive linking in the plain signature once the policy
CMP0022 is set to NEW.
This has follow-on effects for other methods and classes. Further
work on making the use of const cmTarget pointers common can be
done, particularly with a view to generate-time methods.
When using the boost MPL library, one can set a define to increase
the limit of how many variadic elements should be supported. The
default for BOOST_MPL_LIMIT_VECTOR_SIZE is 20:
http://www.boost.org/doc/libs/1_36_0/libs/mpl/doc/refmanual/limit-vector-size.html
If the foo library requires that to be set to 30, and the independent
bar library requires it to be set to 40, consumers of both need to set
it to 40.
add_library(foo INTERFACE)
set_property(TARGET foo PROPERTY INTERFACE_boost_mpl_vector_size 30)
set_property(TARGET foo PROPERTY COMPATIBLE_INTERFACE_NUMBER_MAX boost_mpl_vector_size)
target_compile_definitions(foo INTERFACE BOOST_MPL_LIMIT_VECTOR_SIZE=$<TARGET_PROPERTY:boost_mpl_vector_size>)
add_library(bar INTERFACE)
set_property(TARGET bar PROPERTY INTERFACE_boost_mpl_vector_size 40)
# Technically the next two lines are redundant, but as foo and bar are
# independent, they both set these interfaces.
set_property(TARGET bar PROPERTY COMPATIBLE_INTERFACE_NUMBER_MAX boost_mpl_vector_size)
target_compile_definitions(bar INTERFACE BOOST_MPL_LIMIT_VECTOR_SIZE=$<TARGET_PROPERTY:boost_mpl_vector_size>)
add_executable(user)
target_link_libraries(user foo bar)
Because the TARGET_PROPERTY reads the boost_mpl_vector_size property
from the HEAD of the dependency graph (the user target), and because
that property appears in the COMPATIBLE_INTERFACE_NUMBER_MAX of
the dependencies of the user target, the maximum value for it is
chosen for the compile definition, ie, 40.
There are also use-cases for choosing the minimum value of a number.
In Qt, deprecated API can be disabled by version. Setting the
definition QT_DISABLE_DEPRECATED_BEFORE=0 disables no deprecated
API. Setting it to 0x501000 disables API which was deprecated before
Qt 5.1 etc.
If two dependencies require the use of API which was deprecated in
different Qt versions, then COMPATIBLE_INTERFACE_NUMBER_MIN can be
used to ensure that both can compile.
Make the API for adding targets string based so that it can easily
use cmGeneratorTarget.
Teach the cmIncludeCommand to generate the exported file at
configure-time instead if it is to be include()d.
The RunCMake.ExportWithoutLanguage test now needs a dummy header.h
file as expected error from export() is now reported after the
missing file error.
Multiple libraries in a single buildsystem can be exported to multiple
export-sets.
If a library from one export set depends on a library from
another export set, the export logic generates a check in the targets
file to verify that the target in the other export set is found. That
check is executed at downstream-find_package-time.
However, a target may depend privately on a target in another export
set. In that case, the depend used to also be listed in the required
targets in the targets file. Change the export logic to ignore the
private link entries instead.
The new feature of install(TARGETS ... INCLUDES DESTINATION) introduced
in commit 650e61f8 (Add a convenient way to add the includes install
dir to the INTERFACE., 2013-01-05) introduced this crash. If the
new feature is used with a target which has no
INTERFACE_INCLUDE_DIRECTORIES, a segfault occurred.
First, it prevents a NULL dereference and second it reiterates that
targets without languages are not supported by CMake.
Add a RunCMake.ExportWithoutLanguage test exporting a library without a
languages.
Export the INCLUDES DESTINATION without appending to the
INTERFACE_INCLUDE_DIRECTORIES of the target itself. That way, a target
can be exported multiple times with different INCLUDES DESTINATION
without unintended cross-pollution of export sets.
This patch adds a comment above the block which protects
the exported targets file against multiple inclusion, to make
the file easier to understand for readers.
Alex
This property is generated only for targets which have recorded
policy CMP0022 as NEW, and a compatibility mode is added to
additionally export the old interfaces in that case too.
If the old interfaces are not exported, the generated export files
require CMake 2.8.12. Because the unit tests use a version which
is not yet called 2.8.12, temporarily require a lower version.
dc1d025 OS X: Add test for rpaths on Mac.
8576b3f OS X: Add support for @rpath in export files.
00d71bd Xcode: Add rpath support in Xcode generator.
94e7fef OS X: Add RPATH support for Mac.
Stephen Kelly
Brad King
Ben Boeckel
Rolf Eike Beer
Clinton Stimpson
Alex Neundorf