Maintain a target's internal list of usage requirement include
directories whenever the LINK_LIBRARIES property is set by either
target_link_libraries or set_property.
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.
As of commit 1da75022 (Don't include generator expressions in
old-style link handling., 2012-12-23), such entries are not
included in the LinkLibraries member. Generator expressions in
LinkLibraries are not processed anyway, so port to the new way
of getting link information.
After evaluating the INTERFACE_INCLUDE_DIRECTORIES, of a target in a
generator expression, also read the INTERFACE_INCLUDE_DIRECTORIES of
its link interface dependencies.
That means that code such as this will result in the 'user' target
using /bar/include and /foo/include:
add_library(foo ...)
target_include_directories(foo INTERFACE /foo/include)
add_library(bar ...)
target_include_directories(bar INTERFACE /bar/include)
target_link_libraries(bar LINK_PUBLIC foo)
add_executable(user ...)
target_include_directories(user PRIVATE
$<TARGET_PROPERTY:bar,INTERFACE_INCLUDE_DIRECTORIES>)
Also process the interface include directories from direct link
dependencies for in-build targets.
The situation is similar for the INTERFACE_COMPILE_DEFINITIONS. The
include directories related code is currently more complex because
we also need to store a backtrace at configure-time for the purpose
of debugging includes. The compile definitions related code will use
the same pattern in the future.
This is not a change in behavior, as existing code has the same effect,
but that existing code will be removed in follow-up commits.
This tracking was added during the development of commit 042ecf04
(Add API to calculate link-interface-dependent bool properties
or error., 2013-01-06), but was never used.
It was not necessary to use the content because what is really
useful in that logic is to determine if a property has been implied
to be null by appearing in a LINK_LIBRARIES genex.
I think the motivating usecase for developing the feature of
keeping track of the targets relevant to a property was that I
thought it would make it possible to allow requiring granular
compatibility of interface properties only for targets which
depended on the interface property. Eg:
add_library(foo ...)
add_library(bar ...)
add_executable(user ...)
# Read the INTERFACE_POSITION_INDEPENDENT_CODE from bar, but not
# from foo:
target_link_libraries(user foo $<$<TARGET_PROPERTY:POSTITION_INDEPENDENT_CODE>:bar>)
This obviously doesn't make sense. We require that INTERFACE
properties are consistent across all linked targets instead.
This establishes that linking is used to propagate usage-requirements
between targets in CMake code. The use of the target_link_libraries
command as the API for this is chosen because introducing a new command
would introduce confusion due to multiple commands which differ only in
a subtle way.
6063fef Output include directories as LOG messages, not warnings.
aa66748 Specify the target whose includes are being listed.
d70204a Only output includes once after the start of 'generate-time' when debugging.
0d46e9a Store includes from the same include_directories call together.
During configure-time, GetIncludeDirectories may be called too, for example
if using the export() command. As the content can be different, it should
be output each time then.
1d74ba2 Test evaluation target via export for generator expressions
522bdac Export the INTERFACE_PIC property.
4ee872c Make the BUILD_INTERFACE of export()ed targets work.
1d47cd9 Add a test for the interfaces in targets exported from the build tree.
6c828f9 Move the exported check for file existence.
cfd4f0a Move the exported check for dependencies of targets
d8fe1fc Only generate one check per missing target.
f623d37 Don't write a comment in the export file without the code.
b279f2b Strip consecutive semicolons when preprocessing genex strings.
The Config and IMPORTED_ variants may also contain generator
expressions.
If 'the implementation is the interface', then the result of
evaluating the expressions at generate time is used to populate
the IMPORTED_LINK_INTERFACE_LIBRARIES property.
1) In the case of non-static libraries, this is fine because the
user still has the option to populate the LINK_INTERFACE_LIBRARIES
with generator expressions if that is what is wanted.
2) In the case of static libraries, this prevents a footgun,
enforcing that the interface and the implementation are really
the same.
Otherwise, the LINK_LIBRARIES could contain a generator
expression which is evaluated with a different context at build
time, and when used as an imported target. That would mean that the
result of evaluating the INTERFACE_LINK_LIBRARIES property for
a static library would not necessarily be the 'link implementation'.
For example:
add_library(libone STATIC libone.cpp)
add_library(libtwo STATIC libtwo.cpp)
add_library(libthree STATIC libthree.cpp)
target_link_libraries(libtwo
$<$<STREQUAL:$<TARGET_PROPERTY:TYPE>,STATIC_LIBRARY>:libone>)
target_link_libraries(libthree libtwo)
If the LINK_LIBRARIES content was simply copied to the
IMPORTED_LINK_INTERFACE_LIBRARIES, then libthree links to libone, but
executables linking to libthree will not link to libone.
3) As the 'implementation is the interface' concept is to be
deprecated in the future anyway, this should be fine.
This new method checks that the property FOO on a target is consistent
with the INTERFACE_FOO properties of its dependees. If they are not the
consistent, an error is reported. 'Consistent' means that iff the
property is set, it must have the same boolean value as all other
related properties.
Previously we kept direct link dependencies in OriginalLinkLibraries.
The property exposes the information in the CMake language through the
get/set_property commands. We preserve the OriginalLinkLibraries value
internally to support old APIs like that for CMP0003's OLD behavior, but
the property is now authoritative. This follows up from commit d5cf644a
(Split link information processing into two steps, 2012-11-01).
This will be used later to populate the link interface properties when
exporting targets, and will later allow use of generator expressions
when linking to libraries with target_link_libraries.
Also make targets depend on the (config-specific) union of dependencies.
CMake now allows linking to dependencies or not depending on the config.
However, generated build systems are not all capable of processing
config-specific dependencies, so the targets depend on the union of
dependencies for all configs.
The 'head' is the dependent target to be linked with the current target.
It will be used to evaluate generator expressions with proper handling
of mapped configurations and is used as the source target of properties.
This requires that memoization is done with a key of a pair of target
and config, instead of just config, because now the result also depends
on the target. Removing the memoization entirely is not an option
because it slows cmake down considerably.
Use cmComputeLinkInformation::GetFrameworkPaths to get the list of
framework paths needed by the linker. Drop the now unused framework
information from the old-style cmTarget link dependency analysis.
The ComputePDBOutputDir added by commit 3f60dbf1 (Add
PDB_OUTPUT_DIRECTORY and PDB_NAME target properties, 2012-09-25) falls
back to the current binary directory instead of the target output
directory as before. When no PDB_OUTPUT_DIRECTORY property is set we
instead should fall back to the target output directory where .pdb files
used to go before the new property was added.
2ccca05 Run PDBDirectoryAndName test on MSVC and Intel
efc83b3 Document that PDB_(NAME|OUTPUT_DIRECTORY) are ignored for VS 6
b294457 Verify that PDB_(NAME|OUTPUT_DIRECTORY) are honored in test
3f60dbf Add PDB_OUTPUT_DIRECTORY and PDB_NAME target properties (#10830)
This enables changing the name and output folder of the debug symbol
files produced by MS compilers.
Inspired-by: Thomas Bernard <thomas.bernard@ipetronik.com>
This reverts commit 987e12e2f9.
GenerateTargetManifest is called by the global generator before it
creates the generator targets, so we can't move it to cmGeneratorTarget
yet.
Add a boolean target property NO_SONAME which may be used to disable
soname for the specified shared library or module even if the platform
supports it. This property should be useful for private shared
libraries or various plugins which live in private directories and have
not been designed to be found or loaded globally.
Replace references to <CMAKE_SHARED_LIBRARY_SONAME_${LANG}_FLAG> and
hard-coded -install_name flags with a conditional <SONAME_FLAG> which is
expanded to the value of the CMAKE_SHARED_LIBRARY_SONAME_${LANG}_FLAG
definition as long as soname supports is enabled for the target in
question. Keep expanding CMAKE_SHARED_LIBRARY_SONAME_${LANG}_FLAG in
rules in case third party projects still use it. Such projects would
not yet use NO_SONAME so the adjacent <TARGET_SONAME> will always be
expanded. Make <TARGET_INSTALLNAME_DIR> NO_SONAME aware as well. Since
-install_name is soname on OS X, this should not be a problem if this
variable is expanded only if soname is enabled.
The Ninja generator performs rule variable substitution only once
globally per rule to put its own placeholders. Final substitution is
performed by ninja at build time. Therefore we cannot conditionally
replace the soname placeholders on a per-target basis. Rather than
omitting $SONAME from rules.ninja, simply do not write its contents for
targets which have NO_SONAME. Since 3 variables are affected by
NO_SONAME ($SONAME, $SONAME_FLAG, $INSTALLNAME_DIR), set them only if
soname is enabled.
For now do not allow an OBJECT library to reference other object
libraries. Teach cmTarget::ComputeLinkImplementation to include the
languages of object libraries used by a target.
This library type can compile sources to object files but does not link
or archive them. It will be useful to reference from executable and
normal library targets for direct inclusion of object files in them.
Diagnose and reject the following as errors:
* An OBJECT library may not be referenced in target_link_libraries.
* An OBJECT library may contain only compiling sources and supporting
headers and custom commands. Other source types that are not normally
ignored are not allowed.
* An OBJECT library may not have PRE_BUILD, PRE_LINK, or POST_BUILD
commands.
* An OBJECT library may not be installed, exported, or imported.
Some of these cases may be supported in the future but are not for now.
Teach the VS generator that OBJECT_LIBRARY targets are "linkable" just
like STATIC_LIBRARY targets for the LinkLibraryDependencies behavior.
d662dff Fix shadowed variable warning on dashboard results
f66e735 Fix compiler warning reported on older Borland dashboard.
d90eed4 Fix compiler error reported on older Borland dashboard.
8233636 Update the documentation regarding INCLUDE_DIRECTORIES.
d899eb7 Call ExpandVariablesInString for each target's INCLUDE_DIRECTORIES
c21db87 Make search paths ordered and unique
22021f0 Remove cmMakefile::GetIncludeDirectories
9106b56 Extract and use the INCLUDE_DIRECTORIES target properties.
840509b Keep the INCLUDE_DIRECTORIES target property up to date.
a4d5f7b Add API to get the ordered includes for a target.
8adaee2 CMake: Eliminate cmMakefile::IncludeDirectories
7620932 Remove include flags memoization.
97a5faa Make it safe to call this method without creating duplicates.
edd5303 Refactor GetIncludeFlags to take includes instead of fetching them
Remove partial implementation added by commit ca0230a3 (check in initial
conv library stuff, 2007-02-16) since it was never finished. It does
not make sense for multi-configuration generators since no specific
build configuration is processed at CMake time.
The purpose of the TargetType enumeration was overloaded for install
type because install rules were once recorded as targets. Factor the
install types out into their own enumeration.
Teach the Windows-GNU.cmake platform file to look for Visual Studio
tools matching the target ABI. Add an extra step to the link command
for shared libraries and executables that export symbols and on which a
new GNUtoMS property is set (initialized by the CMAKE_GNUtoMS option).
Tell the GNU linker to output a module definition (.def) file listing
exported symbols in addition to the GNU-format import library (.dll.a).
Pass the .def file to the MS "lib" tool to construct a MS-format DLL
import library (.lib).
Teach the install(TARGETS) command to install the MS import library next
to the GNU one. Teach the install(EXPORT) and export() command to set
the IMPORTED_IMPLIB property pointing at the import library to use the
import library matching the tools in the importing project.
Stephen Kelly
Brad King
Yuchen Deng
Nicolas Despres
Modestas Vainius
David Cole