All cmGlobalGenerator::GenerateBuildCommand call sites that need to
produce a string now generate "cmake --build" commands. The remaining
call sites immediately pass the result to cmSystemTools::RunSingleCommand.
Avoid the intermediate string and argument parsing by directly producing a
vector of strings. Also drop the ignoreErrors argument because no call
sites remain that use it.
Rename cmSystemTools::FindExecutableDirectory to FindCMakeResources.
Teach it to compute the locations of cmake, ctest, cpack, ccmake, and
cmake-gui executables, and the location of CMAKE_ROOT. Provide this
information from static cmSystemTools::Get<resource>() methods.
Refactor code that needs these locations to use the new APIs.
Teach FindCMakeResources to use the OS X system API to lookup the
executable location. When running from the CMake build tree itself,
leave a file in the tree that FindCMakeResources can use to read the
location of the source tree. This avoids the need to compile the source
tree location into a binary that may be installed and used without the
source tree.
Teach the QtDialog on OS X to create a "cmake-gui" symlink in the build
tree next to "cmake" and the other tools, as is already done in the
install tree for the application bundle. This ensures a consistent set
of executables are available in one directory.
Extend the cmGlobalGenerator::GenerateBuildCommand virtual method
signature with a "projectDir" parameter specifying the top of the
project build tree for which the build command will be generated.
Populate it from call sites in cmGlobalGenerator::Build where a
fully-generated build tree should be available.
This is for consistency throughout cmake. The cmsys version exists
becaues uses of auto_ptr types as return types does not work with
some implementations in ancient compilers.
4986d52 Use CPACK_xxx and CMAKE_xxx in a consistent way.
f90223c Fix KWStyle warning
47f0dbd CPack add necessary check to detect/warns/error on ABSOLUTE DESTINATION
6ba055b CPack add easy possibility to warn about CPACK_SET_DESTDIR
CMAKE_xxx vars are now used in the CMake-generated cmake_install.cmake
script while CPACK_xxx equivalent vars are used from within CPack.
CPack is responsible for getting/forwarding definitions of
CPACK_xxxx var corresponding to CMAKE_xxxx when invoking
CMake-generated install scripts.
As a consequence:
CMAKE_ABSOLUTE_DESTINATION_FILES
CMAKE_WARN_ON_ABSOLUTE_INSTALL_DESTINATION
CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION
may be used from outside CPack as well.
e.g.
cmake -DCMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION=1 -P cmake_install.cmake
works as expected.
The [usually] wrong usage of absolute DESTINATION in INSTALL rules
keeps popping-up on the ML. We shall have some way to:
1) easily detect it.
2) forbids this for some CPack generator like NSIS
In fact it should certainly be forbidden for *any* generators
when used on Windows but we may implements that on top of the current
patch.
The patch ask the task to the generated cmake_install.cmake scripts.
Those scripts are a little bit more complicated with that but
iff there are absolute DESTINATION. This cost nothing if relative
DESTINATION are used.
Two new vars are introduced (and documented to handle that):
CPACK_WARN_ON_ABSOLUTE_INSTALL_DESTINATION
and
CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION
For example, when CPACK_<GEN>_COMPONENT_INSTALL and
CPACK_MONOLITHIC_INSTALL are both set. Previously, this
combination of variable settings produced an error without
any explanation. Now, in this case CPACK_MONOLITHIC_INSTALL wins
without trouble.
This is useful for when e.g. CPACK_ARCHIVE_COMPONENT_INSTALL is
globally on and one wants MONOLITHIC install for STGZ (but not
other generators). The same behavior may be obtained by re-setting
CPACK_ARCHIVE_COMPONENT_INSTALL to 0 but in any case the
'both set' case should have been handled without error.
CPACK_COMPONENT_INCLUDE_TOPLEVEL_DIRECTORY should be set by the user
in order to get the toplevel directory included in the archive
whenever a componentized archive is requested. This solves bug #12129
and keeps fully backward compatible behavior.
...when building CPack archive-based packages (.tar.gz and similar)
Rather, put the symlinks-to-directories into the archive as files,
and expect/trust that the things the symlinks point to are also in
the archive.
Also allow generators to override the default packaging method.
Add a ONE_PER_GROUP option so that method can be specified by the user without relying on defaults.
RPM cannot easily 'merge' differents directory into a single RPM
with shared prefix. So more flexibility has been added to generic
CPackGenerator in order to let the specific generator chose the
local installation directory for each component.
This authorize more control because one can set
CPACK_ARCHIVE_COMPONENT_INSTALL to ON globally
and then set it selectively to OFF inside
a CPack project config file.
Sidenote: GetOption ought to be a 'const' method.
The proposed solution is to avoid to CopyIfDifferent any links
found in CPACK_INSTALLED_DIRECTORIES but memorize them instead
then at the end of the processing for each dir do re-create the
link in the installed tree.
Current patch should work if the link are "local" to the directory.
The idea of the patch is to let the install generator define
CPACK_ABSOLUTE_INSTALL_FILES then when CMake is installing
project he will concatenate the list of files and give
it to specific CPack Generator by defining CPACK_ABSOLUTE_INSTALL_FILES
to be the list of ALL files that were installed using absolute destination.
An example of use has been applied to RPM generator which now
tries to automatically build a relocatable package.
The multi-argument CompressFiles(...) method has been replace by the
no-argument PackageFiles() method and 3 more member variables. This
will enable implemention of multi-package generators. Now each specific
generator (which overloads PackageFiles()) may decide to change the name
and/or the number of generated package files.
Since Haiku does not have /usr (and therefore /usr/local), this commit
changes the default install prefix to the equivalent directory of
/boot/common.
See issue #9607.