The LINK_INTERFACE_LIBRARIES property does not apply for STATIC
libraries. The IMPORTED_LINK_INTERFACE_LIBRARIES property does apply
for STATIC libraries. State both explicitly in the documentation.
Also, clarify that the per-configuration version of these properties
completely overrids the generic version.
The compatibility check to allow linking to modules should test for
CMake 2.2, not the unreleased 2.3. See issue #7500. Furthermore, the
message should be more clear about fixing the code instead of setting
CMAKE_BACKWARDS_COMPATIBILITY unless one is just trying to build an
existing project.
In the future some policies may be set to REQUIRED_IF_USED or
REQUIRED_ALWAYS. This change clarifies the error messages users receive
when violating the requirements.
When creating an IMPORTED target for a library that has been found on
disk, it may not be known whether the library is STATIC or SHARED.
However, the library may still be linked using the file found from disk.
Use of an IMPORTED target is still important to allow per-configuration
files to be specified for the library.
This change creates an UNKNOWN type for IMPORTED library targets. The
IMPORTED_LOCATION property (and its per-config equivalents) specifies
the location of the library. CMake makes no assumptions about the
library that cannot be inferred from the file on disk. This will help
projects and find-modules import targets found on disk or specified by
the user.
In switch statements that deal with only a few target types, use a
'default' case for the remaining target types instead of listing them
explicitly. This will make it easier to add more types in the future.
Rename the recently added INTERFACE mode of the target_link_libraries()
command to LINK_INTERFACE_LIBRARIES. This makes it much more distinct
from a normal call to the command, and clearly states its connection to
the property of the same name. Also require the option to appear
immediately after the target name to make it a mode rather than an
option.
It is likely that projects or CMake modules in the future will need to
check the value of a policy setting. For example, if we add a policy
that affects the results of FindXYZ.cmake modules, the module code will
need to be able to check the policy.
found in the system
Qt3 and Qt4 cannot be used together in one project.
Now Qt3/KDE3 and Qt4/KDE4 handle the case that this is done nevertheless
properly, i.e. they fail with FATAL_ERROR if it was REQUIRED and they fail
with just MESSAGE(STATUS ...) and RETURN() if it was not REQUIRED
BUG: make FindQt4 error out with FATAL_ERROR also if it was searched QUIET
Alex
STYLE: this file is mostly uppercase commands, so make all commands
uppercase
ENH: add a status message in case pkgconfig didn't find the package (sync
with the one from KDE)
Alex
During installation the RPATH and RUNPATH entries of ELF binaries are
edited to match the user specification. Usually either one entry is
present or both entries refer to the same string literal. In the case
that they are both present and refer to separate string literals we need
to update both. I have never seen this case in practice, but we should
do this just in case.
Removal of the RPATH and RUNPATH from ELF binaries must work when both
entries are present. Both entries should be removed. Previously only
one would be removed and the other would be blanked because it pointed
at the same string which was zeroed. This fixes gentoo bug number
224901.
Create an INTERFACE option to the target_link_libraries command to help
set the LINK_INTERFACE_LIBRARIES and LINK_INTERFACE_LIBRARIES_DEBUG
properties. This will help users specify link interfaces using
variables from Find*.cmake modules that include the 'debug' and
'optimized' keywords.
The "debug", "optimized", and "general" link library type specifier
arguments to the target_link_library commands are sometimes repeated in
user code due to variable expansion and other complications. Instead of
silently accepting the duplicates and trying to link to a bogus library
like "optimized.lib", warn and ignore the earlier specifiers.
The add_subdirectory() command's EXCLUDE_FROM_ALL option does not
override inter-target dependencies. This change clarifies the
documentation accordingly.
A recent change fixed a case in which CMake incorrectly diagnosed a
circular dependency involving a non-linkable executable target. This
adds a test for that case.
Compiler INFO strings built at preprocessing time encode information
that must appear as a string literal in the resulting binary. We must
make sure the strings appear in the final binary no matter what compiler
and flags are used. The previous implementation worked in most places
but failed with the GNU linker's --gc-sections option which managed to
discard the string. Instead we make the program return value depend on
an element of the string indexed by a runtime program parameter, which
absolutely requires the string to be present.
When an executable target within the project is named in
target_link_libraries for another target, but the executable does not
have the ENABLE_EXPORTS property set, then the executable cannot really
be linked. This is probably a case where the user intends to link to a
third-party library that happens to have the same name as an executable
target in the project (or else will get an error at build time). We
need to avoid making the other target depend on the executable target
incorrectly, since the executable may actually want to link to that
target and this is not a circular depenency.
Brad King
Alexander Neundorf
Bill Hoffman