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.
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.
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.
After reporting an error about circular target dependencies do not try
to continue generation because the dependency computation object is not
in a useful state.
Custom command dependencies that are not full paths or targets may also
match source files. When one does, the full information about the
source file's location and name may be used. This fixes the case when a
custom commands depends by relative path on a source file generated by
another custom command specifying its output by relative path.
A name with an ambiguous extension may only match an unambiguous name
that is extended by one of the fixed set of extensions tried when
finding the source file on disk. This rule makes matching of source
files with ambiguous extensions much less aggressive but still
sufficient.
When generating RPATH entries on the link line using a repeated linker
flag (-R ... -R ... style) do not convert individual entries to a full
path. We need to preserve what the user requested.
When generating escape sequences for the native build tool do not put in
Makefile escapes for paths generated into link scripts. This fixes
putting "$ORIGIN" into the RPATH, and probably some other subtle
problems.
Creation of archive libraries with the unix 'ar' tool should be done
incrementally when the number of object files is large. This avoids
problems with the command line getting too many arguments.
When attempting to load the RPATH out of a non-ELF file cmELF would
crash because the check for a valid file was done with in correct
operator precedence. See bug#7392.
For historical reasons we still support naming of source files without
their extension. Sources without known extensions are located on disk
by iterating through a fixed set of possible extensions. We now want
users to always specify the extension, so the fixed set will not be
expanded and is preserved for compatibility with older projects.
This change adds recognition of extensions of all enabled languages to
avoid checking the disk for files whose extensions are unambiguous but
not in the original fixed set.
In CMake 2.4 the generated link line for a target always preserved the
originally specified libraries in their original order. Dependencies
were satisfied by inserting extra libraries into the line, though it had
some bugs. In CMake 2.6.0 we preserved only the items on the link line
that are not known to be shared libraries. This reduced excess
libraries on the link line. However, since we link to system libraries
(such as /usr/lib/libm.so) by asking the linker to search (-lm), some
linkers secretly replace the library with a static library in another
implicit search directory (developers can override this by using an
imported target to force linking by full path). When this happens the
order still matters.
To avoid this and other potential subtle issues this commit restores
preservation of all non-target items and static library targets. This
will create cases of unnecessary, duplicate shared libraries on the link
line if the user specifies them, but at least it will work. In the
future we can attempt a more advanced analysis to safely remove
duplicate shared libraries from the link line.
We preserve the order and multiplicity of libraries directly linked by a
target as specified by the user. Items known to be shared libraries may
be safely skipped because order preservation is only needed for static
libraries. However, CMake 2.4 did not skip shared libs, so we do the
same when in 2.4 compatibility mode.
We never explicitly specify system library directories in linker or
runtime search paths. Furthermore, libraries in these directories are
always linked by asking the linker to search for them. We need to
generate a warning when explicitly specified search directories contain
files that may hide the system libraries during the search.
This change introduces policy CMP0008 to decide how to treat full path
libraries that do not appear to be valid library file names. Such
libraries worked by accident in the VS IDE and Xcode generators with
CMake 2.4 and below. We support them in CMake 2.6 by introducing this
policy. See policy documentation added by this change for details.
Sometimes we ask the linker to search for a library for which the path
is known but for some reason cannot be specified by full path. In these
cases do not include the library in CMP0003 warnings because we know the
extra paths are not needed for it.
- This case worked accidentally in CMake 2.4, though not in Makefiles.
- Some projects build only with the VS IDE on windows and have this
mistake.
- Support them when 2.4 compatibility is enabled by adding the extension.
CMAKE[_SYSTEM]_(LIBRARY|PROGRAM|INCLUDE|PREFIX)_PATH variables
-moved CMAKE_CROSSCOMPILING from "Variables that modify behaviour" to
"variables that Provide Information", since it should be used only for
testing whether we are currently in cross compiling mode, not for switching
between the modes.
Alex
- The source-file signature of try_compile looks up the language
of the source file using the extension-to-language map so that
it knows what language to enable in the generated project.
- This map needs to be filled before loading a file specified by
CMAKE_USER_MAKE_RULES_OVERRIDE
CMAKE_USER_MAKE_RULES_OVERRIDE_<LANG>
so that the user file may call the try_compile() source-file
signature.
- It must still be re-filled after loading CMake<LANG>Information.cmake
in case the compiler- or platform-specific files added anything.
- See bug #7340.
Brad King
Alexander Neundorf
David Cole
Bill Hoffman