The underlying pkg library always produces a <name>-<version>.pkg
file, so to follow CPACK_PACKAGE_FILE_NAME we need to detect
that and rename appropriately.
FIXES#23034
Rename the booleans 's_ErrorOccured' and 's_FatalErrorOccured' to
's_ErrorOccurred' and 's_FatalErrorOccurred', respectively.
Rename the getters and setters to 'Get[Fatal]ErrorOccurred' and
'Set[Fatal]ErrorOccurred', and fix all uses across the codebase.
- mismatched comments and code,
- remove superfluous log of the "Real package" (which can
still change! log the changed filename if it does),
- the "fix up the package name" code was replacing the
pkg 1.17 suffix by the pkg 1.17 suffix, so it wasn't
really being useful. Whether **any** of the backwards-
compatibility packaging code is useful is another thing.
When using libpkg, the output filename is determined by libpkg
itself, based on information in the manifest: package name and
version, basically. This doesn't necessarily match the name that
CMake has determined via CPACK_TEMPORARY_PACKAGE_FILE_NAME or
CPACK_PACKAGE_FILE_NAME. So reset the CMake-determined list
to match what libpkg will do.
The pkg_create_from_manifest() function was never really intended as
stable API, and bapt@ has asked me to stop using it so the public
API can be stabilized.
Port to pkg_create() with its attendant settings struct.
Since we already have a complete manifest file, we can hand
that (including the embedded plist) to pkg_create().
While here, reintroduce pkg_init(), which lived in downstream patches
for a while and then went away again.
`CollapseCombinedPath` was introduced by commit 551d3343cd (cmDependsC:
Collapse relative include paths, 2013-06-19, v2.8.12~237^2) where the
existing `CollapseFullPath` should have been used instead. Then its use
proliferated slightly. Since `CollapseCombinedPath` is less widely used
and less robust (see issue #19049), use `CollapseFullPath` everywhere
instead.
Issue: #19050
Suppress some cases in `Source/cmGeneratorExpressionNode.cxx` and
`Source/cmUVHandlePtr.h` where a few older compilers require a
user-defined default constructor (with `{}`).
These modules are not meant to be included by user code, they are
only an internal implementation detail for CPack. Having them live
in the main Modules directory with documentation was misleading, so
they have been moved into Modules/Internal/CPack, and their
documentation has been stripped following its move into the new
"CPack Generators" section. No-op modules which contained only
documentation have been removed entirely.
The only module that hasn't been moved is CPackIFW, because it
contains user-facing macros which would be lost if it were moved.
So, the CPackIFW module has been updated with a note explaining what
needs to (eventually) happen.
We now require C++11 support including `override`. Drop use of
the old compatibility macro. Convert references as follows:
git grep -l CM_OVERRIDE -- '*.h' '*.hxx' '*.cxx' |
xargs sed -i 's/CM_OVERRIDE/override/g'
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.
