Case where CPACK_CMAKE_GENERATOR value is non existent or
or contains multiple words that were not quoted was not
handled and produced a segmentation fault.
CPack IFW generator updates:
- Group now can have script;
- Root package (for monolithic or one package installers) can be
configured from group.
CMake updates:
- Native installation (no Unspecified component).
Split the monolithic cmCPackIFWGenerator source into three parts:
cmCPackIFWGenerator, cmCPackIFWInstaller, and cmCPackIFWPackage
to isolate the implementations somewhat.
Add a COMMON option to the cpack_ifw_configure_component command to make
the data component common to its parent group.
Change the default packaging method to ONE_PACKAGE_PER_COMPONENT.
This is not incompatible because the CPack IFW generator has not
yet been in a release.
Since commit 6557382d (stringapi: Use strings for program
paths, 2014-02-24), cmGlobalGenerator::GenerateBuildCommand
takes the make program path as a std::string. Fix the lookup
in cmCPackGenerator::InstallProjectViaInstallCMakeProjects to
use GetSafeDefinition for CMAKE_MAKE_PROGRAM to avoid possible
construction of std::string from a NULL.
Reported-by: Richard Wirth <richard@califax.de>
Changing all categories with LC_ALL causes test failures in some locales.
For example, in some locales, the decimal characer could be a comma instead of period.
Teach set_property and get_property an "INSTALL" property type to be
associated with install-tree file paths. Make the properties available
to CPack for use during packaging. Add a "prop_inst" Sphinx domain
object type for documentation of such properties.
Add a CPACK_DEBIAN_COMPRESSION_TYPE option to set the compression type.
Default to 'gzip' to preserve existing behavior. Use "cmake -E tar"
for 'gzip', 'bzip2', and 'none'. Use system "tar" for 'lzma' and 'xz'.
Use the clang RemoveCStrCalls tool to automatically migrate the
code. This was only run on linux, so does not have any positive or
negative effect on other platforms.
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.
Most of these are turned into strings in the body of the method
(multiple times in some cases). Accept strings to simplify the API and
keep string construction down.
Added a new variable CPACK_WIX_PATCH_FILE that users can point at an
XML patch file. Fragments defined within the patch file will be inserted
at supported insertion points (currently Component, File and Directory).
Creates a hierarchy of WiX features from CPack components and component groups.
Switch to the FeatureTree UI in case components have been defined.
Handles the component REQUIRE and HIDDEN options
and the component group EXPANDED option.
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.
Make the standard --help-* options available from all command-line
tools. Drop options that are no longer supported:
--copyright, --help-full, --help-html, --help-man,
--help-compatcommands, --help-custom-modules
De-duplicate Help/manual/*.1.rst help options by using an
OPTIONS_HELP.txt file included from each manual.
Drop all DefineProperty calls for non-chained properties. Drop the
documentation from the chained ones. The documentation for all
properties is now in Help/prop_*/*.rst files.
We will no longer support full documentation generation from executables
and will instead generate documentation with other tools. Disable (with
a warning left behind) the command-line options:
--copyright
--help-compatcommands
--help-full
--help-html
--help-man
Drop supporting code. Drop manual sections generation from executables.
Remove internal documentation construction APIs. Drop unused sections
See Also, Author, Copyright, Compat Commands, Custom Modules.
bf23891 CPackWIX: Add support for custom WiX templates
155bb01 CMakeCPack: Provide an upgrade guid for WiX
bfa2e29 CPackWIX: Add option to specify the language(s) of the installer
6e51ea9 CPackWIX: Handle multiple shortcuts in the start menu
6d77e1a CPackWIX: Fix MSI package layout regression from parent
8c0e325 CPackWIX: Handle CPACK_PACKAGE_EXECUTABLES (#13967)
WiX provides a lot of functionality for installers that cannot be
supported (easily) in the default WIX.template.in file.
For most users, the default template should be fine. However if users
want to produce merge modules, include custom actions, etc, this new
option allows for a hook into how the wxs is produced.
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.
Only check a release version for the minimum required version. If NSIS
returns a CVS build version string (as when built by Macports), skip the
version check altogether and assume a sufficiently new version. Also
correctly handle the case where the version check fails and the
CPACK_TOPLEVEL_DIRECTORY option is not set.
Co-Author: Graham Menhennitt <graham@menhennitt.com.au>
Remove the old "nocwd" behavior that attempts to provide the "--help"
output when no working directory is available. The long help output
scrolls the real error message out of typical terminal sizes. Also
execute as little code as possible when no working directory exists.
...revealed by the Nightly dashboard runs last night.
Use "size_t" instead of "std::size_t" so that it compiles with
Visual Studio 6, too.
Fix warnings about shadowed "tmp" local variable and ordering of
member variables vs. lines of code in the constructor initializer
list.
Use same technique here with UuidToString as already found in
cmGlobalVisualStudio7Generator::CreateGUID to avoid using a type
that is not defined on older systems... (VS 7.0 and Borland)
This new CPack generator produces an *.msi installer file.
Requires having the WiX Toolset installed in order to work
properly.
Download the WiX Toolset installer "WiX36.exe" here:
http://wix.codeplex.com/releases/view/93929
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.
Previously, setting CPACK_POSTFLIGHT_SCRIPT had no effect in
component mode, when CPACK_COMPONENTS_ALL was set.
In component mode, a .mpkg is created that contains multiple .pkg's.
Because postflight scripts only work in a .pkg, add another .pkg to the
.mpkg and put the postflight script in that.
This is the same approach taken by the PackageMaker GUI when adding
a postflight script to a metapackage.
b47cffa CPack: Use bin subdir when looking for dpkg and rpmbuild
a8c659c Find dpkg and rpmbuild in usual Fink and MacPort paths
848f220 Do not run cpack at CMake time it is not available.
In 2.8.7 running cpack with no arguments would run the packaging iff
a CPackConfig.cmake file is found whereas
In 2.8.8 it displays the help.
This commit restore the 2.8.7.
We should add a test for this but this is not included in this commit.
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
More generally add the check for possible generator "activation" at
runtime depending on a generator specific check.
The dynamic behavior is currently implemented only for MacOS
and should be fully backward compatible for other system.
Inspired-By Tom Hughes <tomtheengineer@gmail.com>
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
0f4dfa6 CPack: Use real path to PackageMaker to find its version file (#12621)
4693cf8 Xcode: Detect new default locations of Xcode 4.3 bits and pieces (#12621)
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.
On machines where a usr/bin/packagemaker symlink is found, we were
unable to find the version.plist file relative to the symlink.
Resolve the symlink first, so we can find it relative to the
real PackageMaker.
The long-standing sporadic failures of CPack tests on the Mac dashboards
are caused by an occasional problem running hdiutil. To compensate for
this, a retry loop was added in the code in a previous commit: a9fa71a4
... but the logic for breaking out of the retry loop was flawed, breaking
out of the loop (and not retrying) when the hdiutil command returns an
error instead of when it returns success.
This commit fixes the flawed logic, bumps up the number of retries from
4 to 10, and adds a half-second delay in between retries.
The delay is specifically added in case a virus checker or spotlight indexer
is temporarily causing the hdiutil failure by hanging onto a newly created
file longer than hdiutil expects it to.
As with all sporadically occurring issues, we'll never know if this is
really fixed all the way. But I'll be happy even if we can only get it to
happen just a bit less often.
Xcode 4.3 installs into "/Applications" by default, from the Mac App Store.
Also, the paths to the available SDKs changed: they are now within the
Xcode.app bundle.
PackageMaker is installed as a separate program, and may be installed
anywhere. It is not installed with Xcode 4.3 by default anymore.
Download the "Auxiliary Tools for Xcode" to get PackageMaker.
Put PackageMaker inside the Xcode.app bundle, in its nested Applications
folder, or put it alongside Xcode in "/Applications" and CMake will find
it.
Update references to "find" paths: add new possible locations for finding
Xcode.app and PackageMaker.app. Prefer the most recent version's locations
first, but keep the old locations as fallback search paths, too.
Thanks to all the contributors who provided and tested out various patches
for fixing this issue. Especially, but by no means limited to:
Francisco Requena Espí, Jamie Kirkpatrick and drfrogsplat.
Stephen Kelly
Domen Vrankar
Calin Cascaval
André Klitzing
Brad King
Nils Gladitz
Konstantin Podsvirov
Bill Hoffman
Daniel Pfeifer
Clinton Stimpson
Ben Boeckel
Sean D'Epagnier
Timo Rothenpieler
Adrien Destugues
Eric NOULARD
Yury G. Kudryashov
Adam J. Weigold
Richard Ulrich
Ian Monroe
Fredrik Axelsson
Andreas Mohr
Petr Kmoch
Paul Kunysch
Gerald Hofmann
Rolf Eike Beer
Eric LaFranchi
David Cole
Nils Gladitz
David Golub
Kitware Robot
Fraser Hutchison