In commit 0c727b90 (install(EXPORT): Force absolute paths for usr-move,
2013-03-08) and commit d4774140 (configure_package_config_file: force
absolute paths for usr-move, 2013-01-24) we supported Linux
distributions implementing the "/usr move" by assuming that installation
to (/usr)?/lib(64)? represents a non-relocatable system package.
When cross-compiling one may prepare a package for installation into a
system location on a target machine but install the package files on the
*host* machine inside another path for use with CMAKE_FIND_ROOT_PATH.
In this case the package development files must still be relocatable.
Handle "/usr move" with a new approach that works with relocatable
files. Teach configure_package_config_file and install(EXPORT) to
generate special logic in a package configuration file or targets file
for installation under (/usr)?/lib(64)?. Teach the file to recognize
when it is loaded through a symlink that refers to the same realpath as
its original install destination. In such a case, use the original
install prefix. Otherwise, compute the prefix relative to the current
file location to make it relocatable.
In VS IDE generators add a pre-build event to perform automoc instead of
using a separate custom target. This reduces the number of targets in the
.sln that need to be loaded by the IDE.
This also works around a VS 11 bug as discussed in issue 13900.
Suggested-by: Hauke Heibel <hauke.heibel@gmail.com>
When called with a non-existent LHS target name the user may be trying
to add file-level dependencies. Clarify the error message to explain
the difference between target-level and file-level dependencies. Point
the reader at the commands and options needed for the latter.
Using XXX as name of the package is ambiguous, since it can be
interpreted as "ALLUPPERCASE" and also as "ExactCase (if the name
is already ALLUPPERCASE)".
After extensive discussion there is the conclusion that ExactCase
is intended, so using a CamelCased name makes that more obvious.
Alex
Modify add_jar to (partly) use cmake_parse_arguments, and to require
using the named argument list INCLUDE_JARS to specify jar files (or jar
targets) to use as dependencies when creating a jar. This preserves the
ability to have such, while restoring the historic behavior that jar
files listed as sources are ignored. (The code now explicitly ignores
them, however, rather than adding them to an unused local variable, so
that it is more clear that nothing is being done with them.)
In GNU.cmake, -isystem is not used if APPLE is set. However, Clang has
pretty much always supported -isystem, so we should always use it.
In the future, GNU.cmake should do a version check to see if -isystem is
supported.
The commit to add the INTERFACE_QT_MAJOR_VERSION in qtbase.git
is 14054d45 (Set the INTERFACE_QT_MAJOR_VERSION to 5., 2013-03-16)
which will be part of Qt 5.1.0.
If there is a Qt 5.0.3 release, there is no guarantee it will
contain that commit. Make sure such a Qt version does not fail
with this test if not.
We can do this check only if the TargetName is non-empty, which means
that we're evaluating INTERFACE_INCLUDE_DIRECTORIES from a linked
dependency which was set using target_link_libraries.
It is possible to have relative paths in INCLUDE_DIRECTORIES already
in CMake 2.8.10.2, so that part will require a policy to fix.
It is considered an error if the INTERFACE_INCLUDE_DIRECTORIES contains
a directory which does not exist, which indicates a programmer error
by the upstream, or a packaging error.
One of the RunCMake.CompatibleInterface tests also needs to be updated
due to this change. Non-existant includes were used in the test, but
are not needed.
Check that source and binary directories are not part of the
INTERFACE_INCLUDE_DIRECTORIES for installed IMPORTED targets.
This is limited to directories which do not contain generator
expressions to evaluate. Such paths can only be checked at time
of use of the imported target, which will be done in a follow up
patch.
The VS version we generate in the .sln header is used by VS when opening
the file through Windows Explorer and possibly elsewhere. Fix our
generators to use version strings known to VS to avoid a drop-down box.
For VS 10, since commit 4f96af44 (Fix VS 10 .sln files for Windows
Explorer, 2009-10-22) we use "Visual Studio 2010" instead of just
"Visual Studio 10". This is correct except that for the Express edition
we need "Visual C++ Express 2010".
For VS 11, since commit f0d66ab4 (VS11: Fix comment generated at the top
of *.sln files, 2011-10-20) we use "Visual Studio 11" in the .sln header
but the preferred value is "Visual Studio 2012" (just as the first
commit mentioned above fixed for VS 10). Also for the Express edition
we need "Visual Studio Express 2012 for Windows Desktop".
The API for retrieving per-config COMPILE_DEFINITIONS has long
existed because of the COMPILE_DEFINITIONS_<CONFIG> style
properties. Ensure that the provided configuration being generated
is also used to evaluate the generator expressions
in cmTarget::GetCompileDefinitions.
Both the generic COMPILE_DEFINITIONS and the config-specific
variant need to be evaluated with the requested configuration. This
has the side-effect that the COMPILE_DEFINITIONS does not need to
be additionally evaluated with no configuration, so the callers can
be cleaned up a bit too.
