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.
- Create MACOSX_BUNDLE_INFO_PLIST target property to specify template.
- Look for MacOSXBundleInfo.plist.in in CMAKE_MODULE_PATH by default.
- See issue #6983.
- Previously this was done implicitly by the check for a target
link language which checked all source full paths.
- The recent change to support computing a link language without
finding all the source files skipped the implicit check.
- This change adds an explicit check to find all source files.
- Place the built library in foo.framework/Versions/A/foo
- Do not create unused content symlinks (like PrivateHeaders)
- Do not use VERSION/SOVERSION properties for frameworks
- Make cmTarget::GetDirectory return by value
- Remove the foo.framework part from cmTarget::GetDirectory
- Correct install_name construction and conversion on install
- Fix MACOSX_PACKAGE_LOCATION under Xcode to use the
Versions/<version> directory for frameworks
- Update the Framework test to try these things
- Policy is WARN by default so projects will build
as they did in 2.4 without user intervention
- Remove CMAKE_LINK_OLD_PATHS variable since it was
never in a release and the policy supercedes it
- Report target creation backtrace in warning message
since policy should be set by that point
- Add cmListFileBacktrace to record stack traces
- Move main IssueMessage method to the cmake class instance
(make the backtrace an explicit argument)
- Change cmMakefile::IssueMessage to construct a backtrace
and call the cmake instance version
- Record a backtrace at the point a target is created
(useful later for messages issued by generators)
- Move computation of extended build-tree rpath
to cmComputeLinkInformation
- Only enable the extended build-tree rpath if
the target will be installed
- Generalize the interface of file(CHRPATH)
- When changing the rpath on installation only
replace the part generated by CMake because
the native tools (ex SunCC on Linux) might have
added their own part to the rpath
- Add cmSystemTools::ChangeRPath method
- Add undocumented file(CHRPATH) command
- When installing use file(CHRPATH) to change the rpath
instead of relinking
- Remove CMAKE_CHRPATH lookup from CMakeFindBinUtils
- Remove CMAKE_USE_CHRPATH option since this should
always work
- Use linker search path -L.. -lfoo for lib w/out soname
when platform sets CMAKE_PLATFORM_USES_PATH_WHEN_NO_SONAME
- Rename cmOrderRuntimeDirectories to cmOrderDirectories
and generalize it for both soname constraints and link
library constraints
- Use cmOrderDirectories to order -L directories based
on all needed constraints
- Avoid processing implicit link directories
- For CMAKE_OLD_LINK_PATHS add constraints from libs
producing them to produce old ordering
- Error if imported target is involved in conflict
- Error for non-imported target conflict unless
CMAKE_BACKWARDS_COMPATIBILITY <= 2.4
- Include OUTPUT_NAME property in error message
- Update add_executable and add_library command documentation
- Move runtime path ordering out of cmComputeLinkInformation
into its own class cmOrderRuntimeDirectories.
- Create an instance of cmOrderRuntimeDirectories for runtime
path ordering and another instance for dependent library
path ordering.
- Replace CMAKE_DEPENDENT_SHARED_LIBRARY_MODE with explicit
CMAKE_LINK_DEPENDENT_LIBRARY_FILES boolean.
- Create CMAKE_LINK_DEPENDENT_LIBRARY_DIRS boolean.
- Create variables to specify -rpath-link flags:
CMAKE_SHARED_LIBRARY_RPATH_LINK_<LANG>_FLAG
CMAKE_EXECUTABLE_RPATH_LINK_<LANG>_FLAG
- Enable -rpath-link flag on Linux and QNX.
- Documentation and error message updates
- Split IMPORTED_LINK_LIBRARIES into two parts:
IMPORTED_LINK_INTERFACE_LIBRARIES
IMPORTED_LINK_DEPENDENT_LIBRARIES
- Add CMAKE_DEPENDENT_SHARED_LIBRARY_MODE to select behavior
- Set mode to LINK for Darwin (fixes universal binary problem)
- Update ExportImport test to account for changes
- Shared libs and executables with exports may now have
explicit transitive link dependencies specified
- Created LINK_INTERFACE_LIBRARIES and related properties
- Exported targets get the interface libraries as their
IMPORTED_LINK_LIBRARIES property.
- The export() and install(EXPORT) commands now give
an error when a linked target is not included since
the user can change the interface libraries instead
of adding the target.
- Imported bundles have the MACOSX_BUNDLE property set
- Added cmTarget::IsAppBundleOnApple method to simplify checks
- Document BUNDLE keyword in INSTALL command
- Updated IMPORTED_LOCATION property documentation for bundles
- Updated ExportImport test to test bundles
- Imported frameworks have the FRAMEWORK property set
- Added cmTarget::IsFrameworkOnApple method to simplify checks
- Also remove separate IMPORTED_ENABLE_EXPORTS property and just use ENABLE_EXPORTS since, like FRAMEWORK, it just represents the target type.
- Document FRAMEWORK keyword in INSTALL command.
- Updated IMPORTED_LOCATION property documentation for Frameworks
- Created cmExportFileGenerator hierarchy to implement export file generation
- Installed exports use per-config import files loaded by a central one.
- Include soname of shared libraries in import information
- Renamed PREFIX to NAMESPACE in INSTALL(EXPORT) and EXPORT() commands
- Move addition of CMAKE_INSTALL_PREFIX to destinations to install generators
- Import files compute the installation prefix relative to their location when loaded
- Add mapping of importer configurations to importee configurations
- Rename IMPORT targets to IMPORTED targets to distinguish from windows import libraries
- Scope IMPORTED targets within directories to isolate them
- Place all properties created by import files in the IMPORTED namespace
- Document INSTALL(EXPORT) and EXPORT() commands.
- Document IMPORTED signature of add_executable and add_library
- Enable finding of imported targets in cmComputeLinkDepends
- This will be useful for imported library dependencies
- Replaces old cmTarget analyze-lib-depends stuff for linking
- Formalizes graph construction and dump
- Explicitly represents dependency inferral sets
- Use BFS of initial dependencies to preserve order
- This is purely an implementation improvement. No interface has changed.
- Create cmComputeLinkInformation class
- Move and re-implement logic from:
cmLocalGenerator::ComputeLinkInformation
cmOrderLinkDirectories
- Link libraries to targets with their full path (if it is known)
- Dirs specified with link_directories command still added with -L
- Make link type specific to library names without paths
(name libfoo.a without path becomes -Wl,-Bstatic -lfoo)
- Make directory ordering specific to a runtime path computation feature
(look for conflicting SONAMEs instead of library names)
- Implement proper rpath support on HP-UX and AIX.
installing without having to link the target again -> can save a lot of time
chrpath is handled very similar to install_name_tool on the mac. If the
RPATH in the build tree file is to short, it is padded using the separator
character.
This is currently disabled by default, it can be enabled using the option
CMAKE_USE_CHRPATH. There are additional checks whether it is safe to enable
it. I will rework them and use FILE(READ) instead to detect whether the
binaries are actually ELF files.
chrpath is available here
http://www.tux.org/pub/X-Windows/ftp.hungry.com/chrpath/
or kde svn (since a few days): http://websvn.kde.org/trunk/kdesupport/chrpath/
Alex
Brad King
Bill Hoffman
Alexander Neundorf
Ken Martin
Amitha Perera
David Cole