This will allow per-config destinations for targets in EXPORT sets.
Using multiple install(TARGETS) with separate CONFIGURATIONS is
rejected as a target appearing more than once in an export set.
Now instead one can write
install(TARGETS foo EXPORT exp DESTINATION lib/$<CONFIG>)
to get a single logical membership of the target in the export set
while still having a per-config destination.
Replace the GetInstallDestination method, which looked up the
Destination ivar, with a new ConvertToAbsoluteDestination method that
takes the nominal destination as an argument. Update call sites
accordingly. This will allow some clients to transform the install
destination before calling the method.
Even though 10.5 supports @rpath, the support is not complete
enough for CMake. For instance, install_name_tool doesn't support
adding and removing rpaths.
Also modifying BundleUtilities test to remove an undesirable cmake
generated runtime path. The intent was to build with the install
rpath as is done with the other cases in this test.
Create a cmInstallGenerator::MessageLevel enumeration for future use in
specifying install message verbosity. Thread values of the type through
constructors and save the value as a member of cmInstallGenerator.
Use only a "MessageDefault" value for now.
Casts from std::string -> cmStdString were high on the list of things
taking up time. Avoid such implicit casts across function calls by just
using std::string everywhere.
The comment that the symbol name is too long is no longer relevant since
modern debuggers alias the templates anyways and the size is a
non-issue since the underlying methods are generated since it's
inherited.
When using link_directories() and including CMAKE_CFG_INTDIR,
one can end up with duplicate RPATHs in the binary which
install_name_tool cannot fix without corrupting the binary.
Also, the cmake_install.cmake file has been fixed to correctly
handle these generator specific variables.
This target type only contains INTERFACE_* properties, so it can be
used as a structural node. The target-specific commands enforce
that they may only be used with the INTERFACE keyword when used
with INTERFACE_LIBRARY targets. The old-style target properties
matching LINK_INTERFACE_LIBRARIES_<CONFIG> are always ignored for
this target type.
The name of the INTERFACE_LIBRARY must match a validity generator
expression. The validity is similar to that of an ALIAS target,
but with the additional restriction that it may not contain
double colons. Double colons will carry the meaning of IMPORTED
or ALIAS targets in CMake 2.8.13.
An ALIAS target may be created for an INTERFACE library.
At this point it can not be exported and does not appear in the
buildsystem and project files are not created for them. That may
be added as a feature in a later commit.
The generators need some changes to handle the INTERFACE_LIBRARY
targets returned by cmComputeLinkInterface::GetItems. The Ninja
generator does not use that API, so it doesn't require changes
related to that.
The commits 9db31162 (Remove CMake-language block-end command
arguments, 2012-08-13) and 77543bde (Convert CMake-language
commands to lower case, 2012-08-13) changed most cmake code
to use lowercase commands and no parameters in termination
commands. However, those changes excluded cmake code generated
in c++ by cmake.
Make a similar style change to code generated by cmake.
RPATH support is activated on targets that have the MACOSX_RPATH
property turned on.
For install time, it is also useful to set INSTALL_RPATH to help
find dependent libraries with an @rpath in their install name.
Also adding detection of rpath conflicts when using frameworks.
Make handling of directory separators consistent between
non-bundle and bundle code.
Remove xcode specific flag from cmTarget when getting install_name.
Add (more) consistent convenience functions in cmTarget to get
directories inside of bundles and frameworks to add files to.
This refactor also fixes bug #12263 where frameworks
had the wrong install name when SKIP_BUILD_RPATH.
Also make install_name for frameworks consistent between Makefile
and Xcode generator.
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.
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.
During installation of a target we generate "tweak" rules to update the
installed file (RPATH, strip, ranlib, etc.). However, some targets
install multiple files, such as the versioned names of a shared library.
Previously the extra files for a target have always been symbolic links,
but for cross-compiling from Windows to UNIX they may need to be copies.
This commit teaches the generated install scripts to loop over all files
installed for the target to apply tweaks to those that are not symlinks.
See issue #9171.
In cmInstallTargetGenerator::GenerateScriptForConfig we were computing
the full 'from' paths for all target files to be installed, but only
computing a 'to' path for the "main" target file. This commit teaches
the method to compute both 'from' and 'to' paths for every target file
to be installed. The result is cleaner, easier to follow, and will
allow installation tweaks to be added later on all target files.
The cmInstallTargetGenerator methods AddStripRule and AddRanlibRule do
not need the target type argument. They can simply use the type of the
target for which the generator instance was created.
This converts the CMake license to a pure 3-clause OSI-approved BSD
License. We drop the previous license clause requiring modified
versions to be plainly marked. We also update the CMake copyright to
cover the full development time range.
A new cmScriptGenerator base class factors out the non-install-specific
part of cmInstallGenerator. This will be useful for other generators
that want per-configuration functionality.
When we install a target on Mac, we generate a call to install_name_tool to fix
install_name entries in the target for shared libraries it links. This change
makes the step ignore entries for imported targets since their install_name
will not change and cmTarget cannot produce a mapping for them. This fixes the
error
GetLibraryNamesInternal called on imported target: kdelibs
seen by kde folks.
In single-configuration generators a target installation rule should
apply to all configurations for which the INSTALL command was specified.
The configuration in which the target is built does not matter.
In multi-configuration generators each installation rule must be
associated with a particular build configuration to install the proper
file. The set of configurations for which rules are generated is the
intersection of the build configurations and those for which the INSTALL
command was specified.
- If new RPATH is empty then remove the entry completely
- Preserve file modification time so installation is not repeated
- If installed file already exists remove it if its RPATH
does not match that expected
- 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
Stephen Kelly
Brad King
Sean McBride
Clinton Stimpson
Tim Blechmann
Ben Boeckel
Alex Neundorf