| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This passes the build configuration to cmTarget methods IsChrpathUsed
and NeedRelinkBeforeInstall. Later these methods will use the value.
|
|
|
|
|
| |
This cleans up cmInstallTargetGenerator's code that computes the build
tree location of a target under each configuration.
|
|
|
|
|
| |
The undocumented file(INSTALL) command used to support a PROPERTIES
option, but no install code still uses it. This removes the option.
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
and not the symlink.
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
| |
change.
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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 real name instead of link for location of versioned targets
- Error when a target is exported multiple times
|
| |
|
|
|
|
|
|
|
| |
- Add NAMELINK_ONLY and NAMELINK_SKIP to INSTALL command
- Options select a \"namelink\" mode
- cmInstallTargetGenerator selects files/link based on mode
- See bug #4419
|
|
|
|
|
|
|
|
|
| |
- Motivation:
- It depended on the order of installation
- It supported only a single destination for each target
- It created directory portions of an install name without user request
- Updated ExportImport test to install targets in an order that expoed
this bug
|
|
|
|
| |
target from cmComputeLinkInformation instead of duplicating the computation.
|
|
|
|
| |
generators to share link information while only computing it once per configuration for a target. Use it to simplify the chrpath feature.
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
configurations.
- 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
|
| |
|
|
|
|
| |
Alex
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
and install now. More work needed on the packaging step. See Tests/Framework for example use.
|
|
|
|
| |
Mac. Change Application to Applications in the BundleTest. Also correct small typo (tcl->Tcl) noted in bug 4572.
|
|
|
|
|
|
| |
-move the array behind the if, it's unused before it
Alex
|
|
|
|
| |
target. Added a foo/preinstall version of targets that need relinking so that exclude-from-all targets can be manually relinked for installation.
|
| |
|
|
|
|
| |
and per-configuration testing is now done in cmake code instead of in the FILE(INSTALL) command. The generation of the cmake code to do these tests is centralized in cmInstallGenerator. Old-style shared library versioning and component/config support code has been removed from FILE(INSTALL). This commit is surrounded by the tags CMake-InstallGeneratorCleanup2-pre and CMake-InstallGeneratorCleanup2-post.
|
|
|
|
| |
on OSX. This addresses bug#4534.
|
| |
|
|
|
|
| |
be installed is now separately handled instead of using variables to store per-configuration names. For targets the component and configuration install-time tests are now done in the install script instead of in the FILE(INSTALL) command. This cleans things up like not trying to strip a file that was optionally not installed. It also simplifies the code for install_name adjustment on OSX. This commit is surrounded by the tags CMake-InstallGeneratorCleanup1-pre and CMake-InstallGeneratorCleanup1-post.
|
|
|
|
|
|
|
|
|
| |
-move std::string Destination to cmInstallGenerator, since all (except
the script one) have it and add a const accessor so it can be queried
-use temporary variables in cmInstallCommand for the generators so they can be reused easier
-some more const
Alex
|
|
|
|
|
|
|
| |
GetScriptReference, and make the logic for getting the filename public, so
it can be used e.g. for exporting
Alex
|
|
|
|
|
|
| |
libs have an extra symbol table so they still work stripped
Alex
|
|
|
|
| |
Alex
|
|
|
|
|
|
|
|
|
|
| |
"imported" executable target. This can then be used e.g. with
ADD_CUSTOM_COMMAND() to generate stuff. It adds a second container for
"imported" targets, and FindTarget() now takes an additional argument bool
useImportedTargets to specify whether you also want to search in the
imported targets or only in the "normal" targets.
Alex
|
|
|
|
|
|
|
|
| |
CMAKE_INSTALL_NAME_TOOL in the cache" from
cmInstallTargetGenerator.cxx to Darwin.cmake
Alex
|
|
|
|
| |
Alex
|
| |
|
|
|
|
|
|
| |
ENH: add hack to make new cmake work with older existing cmake build trees
Alex
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-add a RESULT_VARIABLE to INCLUDE()
-add CMAKE_TOOLCHAIN_FILE for specifiying your (potentially crosscompiling) toolchain
-have TRY_RUN() complain if you try to use it in crosscompiling mode (which were compiled but cannot run on this system)
-use CMAKE_EXECUTABLE_SUFFIX in TRY_RUN(), probably TRY_RUN won't be able to
run the executables if they have a different suffix because they are
probably crosscompiled, but nevertheless it should be able to find them
-make several cmake variables presettable by the user: CMAKE_C/CXX_COMPILER, CMAKE_C/CXX_OUTPUT_EXTENSION, CMAKE_SYSTEM_NAME, CMAKE_SYSTEM_INFO_FILE
-support prefix for GNU toolchains (arm-elf-gcc, arm-elf-ar, arm-elf-strip etc.)
-move ranlib on OSX from the file command to a command in executed in cmake_install.cmake
-add support for stripping during install in cmake_install.cmake
-split out cl.cmake from Windows-cl.cmake, first (very incomplete) step to support MS crosscompiling tools
-remove stdio.h from the simple C program which checks if the compiler works, since this may not exist for some embedded platforms
-create a new CMakeFindBinUtils.cmake which collects the search fro ar, ranlib, strip, ld, link, install_name_tool and other tools like these
-add support for CMAKE_FIND_ROOT_PATH for all FIND_XXX commands, which is a
list of directories which will be prepended to all search directories, right
now as a cmake variable, turning it into a global cmake property may need
some more work
-remove cmTestTestHandler::TryExecutable(), it's unused
-split cmFileCommand::HandleInstall() into slightly smaller functions
Alex
|
|
|
|
| |
targets. The module import libraries should never be used but some windows compilers always create them for .dll files since there is no distinction from shared libraries on that platform. The executable import libraries may be used to create modules that when loaded bind to symbols from the executables. This is an enhancement related to bug#4210 though not requested by it explicitly.
|
|
|
|
| |
installation file name for executable targets.
|
|
|
|
| |
directory containing the import library. This is an incremental step for bug#4210.
|