We create target property "LINK_INTERFACE_MULTIPLICITY" and a per-config
version "LINK_INTERFACE_MULTIPLICITY_<CONFIG>". It sets the number of
times a linker should scan through a mutually dependent group of static
libraries. The largest value of this property on any target in the
group is used. This will help projects link even for extreme cases of
cyclic inter-target dependencies.
We creates methods IsDLLPlatform() and HasImportLibrary(). The former
returns true on Windows. The latter returns whether the target has a
DLL import library. It is true on Windows for shared libraries and
executables with exports.
The commit "Consider link dependencies for link language" taught CMake
to propagate linker language preference from languages compiled into
libraries linked by a target. It turns out this should only be done for
some languages, such as C++, because normally the language of the
program entry point (main) should be used.
We introduce variable CMAKE_<LANG>_LINKER_PREFERENCE_PROPAGATES to tell
CMake whether a language should propagate its linker preference across
targets. Currently it is true only for C++.
This factors the decision logic out of cmTarget::ComputeLinkClosure into
dedicated class cmTargetSelectLinker. We replace several local
variables with a single object instance, and organize code into methods.
Now that languages are part of the link interface of a target we need to
export/import the information. A new IMPORTED_LINK_INTERFACE_LANGUAGES
property and per-config IMPORTED_LINK_INTERFACE_LANGUAGES_<CONFIG>
property specify the information for imported targets. The export() and
install(EXPORT) commands automatically set the properties.
This teaches cmTarget to account for the languages compiled into link
dependencies when determining the linker language for its target.
We list the languages compiled into a static archive in its link
interface. Any target linking to it knows that the runtime libraries
for the static archive's languages must be available at link time. For
now this affects only the linker language selection, but later it will
allow CMake to automatically list the language runtime libraries.
The commit "Do not compute link language for LOCATION" was wrong. The
variables
CMAKE_STATIC_LIBRARY_PREFIX_Java
CMAKE_STATIC_LIBRARY_SUFFIX_Java
are used for building Java .jar files. This commit re-enables the
feature and documents the variables:
CMAKE_EXECUTABLE_SUFFIX_<LANG>
CMAKE_IMPORT_LIBRARY_PREFIX_<LANG>
CMAKE_IMPORT_LIBRARY_SUFFIX_<LANG>
CMAKE_SHARED_LIBRARY_PREFIX_<LANG>
CMAKE_SHARED_LIBRARY_SUFFIX_<LANG>
CMAKE_SHARED_MODULE_PREFIX_<LANG>
CMAKE_SHARED_MODULE_SUFFIX_<LANG>
CMAKE_STATIC_LIBRARY_PREFIX_<LANG>
CMAKE_STATIC_LIBRARY_SUFFIX_<LANG>
Instead of making separate, repetitive entries for the _<LANG> variable
documentation, we just mention the per-language name in the text of the
platform-wide variable documentation. Internally we keep undocumented
definitions of these properties to satisfy CMAKE_STRICT mode.
This passes the build configuration to most GetLinkerLanguage calls. In
the future the linker language will account for targets linked in each
configuration.
The LOCATION property requires the full file name of a target to be
computed. Previously we computed the linker language for a target to
look up variables such as CMAKE_SHARED_LIBRARY_SUFFIX_<LANG>. This led
to locating all the source files immediately instead of delaying the
search to generation time. In the future even more computation will be
needed to get the linker language, so it is better to avoid it.
The _<LANG> versions of these variables are undocumented, not set in any
platform file we provide, and do not produce hits in google. This
change just removes the unused feature outright.
The new method centralizes loops that process raw OriginalLinkLibraries
to extract the link implementation (libraries linked into the target)
for each configuration. Results are computed on demand and then cached.
This simplifies link interface computation because the default case
trivially copies the link implementation.
These member structures are accessed only in the cmTarget implementation
so they do not need to be defined in the header. This cleanup also aids
Visual Studio 6 in compiling them.
The config-to-interface map in cmTarget should use case-insensitive
configuration names. The change avoids repeating work if the given
configuration has a different case than one already computed.
This fixes a dumb logic error introduced by the centralization of link
interface computation. It prevented link directories from alternate
configurations from getting listed by the OLD behavior of CMP0003 for
targets linked as transitive dependencies.
This method previously required the global generator to be passed, but
that was left from before cmTarget had its Makefile member. Now the
global generator can be retrieved automatically, so we can drop the
method argument.
When LINK_INTERFACE_LIBRARIES is not set we use the link implementation
to implicitly define the link interface. These changes centralize the
decision so that all linkable targets internally have a link interface.
This moves code implementing policy CMP0004 into cmTarget::CheckCMP0004.
The implementation is slightly simpler and can be re-used outside of
cmComputeLinkDepends.
This fixes cmTarget::GetLinkInterface to compute and return the link
interface in an exception-safe manner. We manage the link interface
returned by cmTarget::ComputeLinkInterface using auto_ptr.
This creates cmTarget::GetOutputInfo to compute, cache, and lookup
target output directory information on a per-configuration basis. It
avoids re-computing the information every time it is needed.
The VMS posix path emulation does not handle multiple '.' characters in
file names in all cases. This avoids adding extra '.'s to file and
directory names for target directories and generated files.
Internally cmTarget was passing the target type in several name
computation signatures to support computation of both shared and static
library names for one target. We no longer need to compute both names,
so this change simplifies the internals by using the GetType method and
dropping the type from method signatures.
This property was left from before CMake always linked using full path
library names for targets it builds. In order to safely link with
"-lfoo" we needed to avoid having both shared and static libraries in
the build tree for targets that switch on BUILD_SHARED_LIBS. This meant
cleaning both shared and static names before creating the library, which
led to the creation of CLEAN_DIRECT_OUTPUT to disable the behavior.
Now that we always link with a full path we do not need to clean old
library names left from an alternate setting of BUILD_SHARED_LIBS. This
change removes the CLEAN_DIRECT_OUTPUT property and instead uses its
behavior always. It removes some complexity from cmTarget internally.
This creates target properties ARCHIVE_OUTPUT_NAME, LIBRARY_OUTPUT_NAME,
and RUNTIME_OUTPUT_NAME, and per-configuration equivalent properties
ARCHIVE_OUTPUT_NAME_<CONFIG>, LIBRARY_OUTPUT_NAME_<CONFIG>, and
RUNTIME_OUTPUT_NAME_<CONFIG>. They allow specification of target output
file names on a per-type, per-configuration basis. For example, a .dll
and its .lib import library may have different base names.
For consistency and to avoid ambiguity, the old <CONFIG>_OUTPUT_NAME
property is now also available as OUTPUT_NAME_<CONFIG>.
See issue #8920.
This creates method cmTarget::GetOutputTargetType to compute the output
file type 'ARCHIVE', 'LIBRARY', or 'RUNTIME' from the platform and
target type. It factors out logic from the target output directory
computation code for later re-use.
Linking to a Windows shared library (.dll) requires only its import
library (.lib). This teaches CMake to recognize SHARED IMPORTED library
targets that set only IMPORTED_IMPLIB and not IMPORTED_LOCATION.
When an IMPORTED target provides no generic configuration and no match
for a desired configuration then we choose any available configuration.
This change corrects the choice when the first listed available
configuration does not really have a location.
The add_definitions() command and COMPILE_DEFINITIONS dir/tgt/src
properties support preprocessor definitions with values. Previously
values were not supported in the VS6 generator even though the native
tool supports them. It is only values with spaces that VS6 does not
support. This enables support and instead complains only for values
with spaces. See issue #8779.
The RPATH target properties are initialized by CMAKE_<prop> variables at
target creation time. This notes the feature in the property
documentation. It is already noted in the variable documentation.
This defines global, directory, and target properties
RULE_LAUNCH_COMPILE, RULE_LAUNCH_LINK, and RULE_LAUNCH_CUSTOM. Their
values specify 'launcher' command lines which are prefixed to compile,
link, and custom build rules by Makefile generators.
This creates a new LABELS property for targets and source files. We
write the labels of each target and its source files in target-specific
locations in the build tree for future use.
This creates method cmTarget::GetSupportDirectory to compute a
target-specific support directory in the build tree. It uses the
"CMakeFiles/<name>.dir" convention already used by the Makefile
generators. The method will be useful for any code that needs to
generate per-target information into the build tree for use by CMake
tools that do not run at generate time.
Previously cmTarget::GetLocation and cmTarget::GetFullPath would return
for Mac AppBundles the top-level bundle directory but without the .app
extension. We worked around this at the call sites. This fixes the
methods and removes the work-arounds. See issue #8406.
Previously we left the LOCATION property undefined for imported targets
since it should no longer be used for non-imported targets. However, in
the case we do not know the name of an available imported configuration,
it is more readable to get the LOCATION property than LOCATION_<CONFIG>
for a bogus configuration <CONFIG>. This enables LOCATION for imported
targets and returns an unspecified available imported configuration.
The CMAKE_<CONFIG>_POSTFIX variable and <CONFIG>_POSTFIX property were
not documented. This updates the CMAKE_DEBUG_POSTFIX and DEBUG_POSTFIX
documentation to refer to the more general variable/property. It also
clarifies that the variable is used as the property default only for
non-executable targets. See issue #7868.
In some cases it may be useful to compute a "link" line for a static
library even though it will not be put in the generated build system.
This removes the assertion which previously diallowed the case.
A Mac OS X Framework should provide a Resources/Info.plist file
containing meta-data about the framework. This change generates a
default Info.plist for frameworks and provides an interface for users to
customize it.
The LINK_INTERFACE_LIBRARIES target property may not contain the
"debug", "optimized", or "general" keywords. These keywords are
supported only by the target_link_libraries (and link_libraries) command
and are not a generic library list feature in CMake. When a user
attempts to add one of these keywords to the property value, we now
produce an error message that refers users to alternative means.
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.
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.
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.
Brad King
Bill Hoffman
Alexander Neundorf