Merge use of SetFilterOption() into more abstract thread count
in cmArchiveWrite constructor.
libarchive defaulting of threads for threads == 0 seems to be
configuration dependent. Preemptively default thread count via
std::thread::hardware_concurrency().
Also allow negative values for the thread count in which case
the detected hardware concurrency is also used but the given
absolute thread count is used as an upper limit.
CPack learned the `CPACK_PRE_BUILD_SCRIPTS`, `CPACK_POST_BUILD_SCRIPTS`,
and `CPACK_PACKAGE_FILES` variables.
The first two are lists of scripts to perform
- after pre-install files into a staging directory and before
producing the resulting packages
- after produsing the packages
The post-build script(s) also get the list of actually produced
packages in the `CPACK_PACKAGE_FILES`.
Issue: #19077
* In summary:
* we configure generators, not the generated installers
* we generate installers or source packages, not source package installers
* In Introduction:
* Make paragraph on binary installers more concise
* Remove example that refered to CMake source tree
* Add paragraph on source packages
* omit the parenthesis on graphical installers
The CPack OSXX11 generator has not had any updates since 2011 except as
part of sweeping maintenance changes. It also creates packages with a
OSXScriptLauncher binary that has only ppc and i386 architectures which
are not supported by Apple anymore. Furthermore, the generator is not
even mentioned in our documentation. Add a deprecation warning.
Fixes: #20235
In commit da5ac4bb60 (cpack: Add `CPACK_INSTALL_CMAKE_CONFIGURATIONS`
variable, 2019-07-10, v3.16.0-rc1~165^2) we added both the variable
and support for `cpack -C` with multiple configurations. Drop the
variable because the `package` target cannot ensure that all of the
configurations are built. Keep the command-line interface so that
it can be used manually in scripts.
Fixes: #19918
For the multi-configuration generators one can specify the list
of configurations to include in the package.
E.g. having a project, where debug libraries have a suffix to
distinct them from the release builds, one can build the package
containing both `Debug` and `Release` binaries.
The singular name `CPACK_INSTALL_SCRIPT` has existed but was not linked
from the CPack documentation. Also, it supported multiple values and
should have had a plural name. Add a plural-named alternative now.
If both `CPACK_INSTALL_SCRIPTS` and `CPACK_INSTALL_SCRIPT` are set then
ignore the latter with a warning.
Signed-off-by: Alex Turbov <i.zaufi@gmail.com>
In particular, make clear that package/installer generators
are not the makefile generators of the cmake command.
Also insert sections in CPack doc, and capitalize section titles.
In commit v3.12.0-rc1~136^2 (CPack: Use project version as default for
`CPACK_PACKAGE_VERSION`, 2018-04-29) we did not account for the value of
`CMAKE_PROJECT_VERSION_{MAJOR,MINOR,PATCH}` having `0`. Fix the logic
to distinguish between unprovided version components and `0` components.
While at it, add a test case covering the behavior described in the
documentation by the original commit. The number of version components
in the package name should match those provided to the `project()`
command `VERSION` option.
Fixes: #18199
Create a CPack generator that uses `nuget.exe` to create packages:
https://docs.microsoft.com/en-us/nuget/what-is-nuget
NuGet packages could be easily produced from a `*.nuspec` file (running
`nuget pack` in the directory w/ the spec file). The spec filename does
not affect the result `*.nupkg` name -- only `id` and `version` elements
of the spec are used (by NuGet).
Some implementation details:
* Minimize C++ code -- use CMake script do to the job. It just let the
base class (`cmCPackGenerator`) to preinstall everything to a temp
directory, render the spec file and run `nuget pack` in it, harvesting
`*.nupkg` files...;
* Ignore package name (and use default paths) prepared by the base class
(only `CPACK_TEMPORARY_DIRECTORY` is important) -- final package
filename is a responsibility of NuGet, so after generation just scan the
temp directory for the result `*.nupkg` file(s) and update
`packageFileNames` data-member of the generator;
* The generator supports _all-in-one_ (default), _one-group-per-package_
and _one-component-per-package_ modes.
* Introduce `CMAKE_PROJECT_VERSION` and the corresponsing components:
`CMAKE_PROJECT_VERSION_MAJOR`, `CMAKE_PROJECT_VERSION_MINOR`,
`CMAKE_PROJECT_VERSION_PATCH` and `CMAKE_PROJECT_VERSION_TWEAK`.
* `CPack` module use `CMAKE_PROJECT_VERSION_MAJOR`,
`CMAKE_PROJECT_VERSION_MINOR` and `CMAKE_PROJECT_VERSION_PATCH`
to initialize corresponsing CPack variables.
This is primarily a cleanup of the cpack(1) page. The cpack.cxx file
and CPack module were also updated to make the docs relating to
the generator specification and option names consistent in all
three places.
Introduces CPACK_DEFAULT_DIRECTORY_INSTALL_PERMISSIONS
variable which adds support for functionality introduced
by CMAKE_DEFAULT_DIRECTORY_INSTALL_PERMISSIONS variable.
Fixes#17333
# Conflicts:
# Help/release/dev/cmake-default-dir-install-permissions.rst
Adds an option CPACK_ENABLE_FREEBSD_PKG to allow CPack to look
for FreeBSD's libpkg / pkg(8). If this is set and the libpkg
headers and library are found (which they will be, by default,
on any FreeBSD system), then add a FreeBSD pkg(8) generator.
The FreeBSD package tool pkg(8) uses tar.xz files (.txz) with two
metadata files embedded (+MANIFEST and +COMPACT_MANIFEST).
This introduces a bunch of FreeBSD-specific CPACK_FREEBSD_PACKAGE_*
variables for filling in the metadata; the Debian generator does
something similar. Documentation for the CPack CMake-script is styled
after the Debian generator.
Implementation notes:
- Checks for libpkg -- the underlying implementation for pkg(8) --
and includes FreeBSD package-generation if building CMake on
a UNIX host. Since libpkg can be used on BSDs, Linux and OSX,
this potentially adds one more packaging format. In practice,
this will only happen on FreeBSD and DragonflyBSD.
- Copy-paste from cmCPackArchiveGenerator to special-case
the metadata generation and to run around the internal
archive generation: use libpkg instead.
- Generating the metadata files is a little contrived.
- Most of the validation logic for package settings is in
CPackFreeBSD.cmake, as well as the code that tries to re-use
packaging settings that may already be set up for Debian.
- libpkg has its own notion of output filename, so we have
another contrived bit of code that munges the output file
list so that CPack can find the output.
- Stick with C++98.
It is quite often the project description has used in a real world software.
Examples include:
* part of a help screen of the application
* builtin resources (`*.rc` files, data for "About" dialog of a GUI app, & etc)
* most generators for CPack can use it
* it could be used by documentary software (Doxygen, Sphinx) which is usually
integrated to CMake based projects via `add_custom_target()`
Now `project()` call learned an optional `DESCRIPTION` parameter with a
short string describing a project. Being specified, it would set the
`PROJECT_DESCRIPTION` variable which could be used in `configure_file()`
or whatever user wants. Also `PROJECT_DESCRIPTION` is a default value
for `CPACK_PACKAGE_DESCRIPTION_SUMMARY`.
