Set progress callback on cmake instance used by CPack. The progress
callback is used to output STATUS messages which are otherwise missing
when issued from e.g. CPack External staging scripts.
Fixes: #18567
The only format supported from the ones available within cpack is
gnutar, which supports large numbers encoded in base-256, and long
filenames and linknames. PAX is not and has never been a supported
format by dpkg.
Fixes: #18620
Ext and External were used inconsistently in the code and the
docs. This change converts all uses of Ext to External, including
within variable names used by the generator.
CPACK_EXT_ENABLE_STAGING enables optional staging
and CPACK_EXT_PACKAGE_SCRIPT allows to specify an optional
script file that can package staged files via an
external packaging tool.
Issue: #18236
After changing the ``cmGeneratedFileStream`` methods to accept
``std::string const&`` instead of ``const char*`` we don't
need to call ``std::string::c_str`` anymore when passing
a ``std::string`` to a ``cmGeneratedFileStream`` method.
This patch removes all redundant ``std::string::c_str``
calls when passing a string to a ``cmGeneratedFileStream`` method.
It was generated by building CMake with clang-tidy enabled using
the following options:
-DCMAKE_CXX_CLANG_TIDY=/usr/bin/clang-tidy-4.0;-checks=-*,readability-redundant-string-cstr;-fix;-fix-errors
CPack creates cpack_variables.wxi in the build directory. In the WiX
template it can be used by <?include "cpack_variables.wxi"?> because
the template is configured into main.wxs in the build directory.
Because the extra source files are in the source directory it was necessary to use
<?include "$(sys.CURRENTDIR)_CPack_Packages\win32\WIX\cpack_variables.wxi"?>.
This requires knowledge about the build directory structure and
is avoided by this change by adding the build directory to the IncludeSearchPaths.
This generator doesn't actually package the files. Instead, it
provides a metadata JSON file that can be used by external packaging
software to do its own packaging. This JSON file provides information
about the components, component groups, installation types, and CMake
projects.
This refactoring will allow cmCPackExtGenerator to skip the install
step while still gathering up information about the CPack components
and groups. Besides, this function was too long, and needed to be
broken up anyway.
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.
Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`. Use `clang-format` version 6.0.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
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.
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.
In commit v3.11.0-rc1~68^2 (CPack: accept --trace and --trace-expand,
2017-12-09) a nullptr dereference was added that occurs when
`cpack -G NotAGenerator` is invoked. Add the needed condition.
Fixes: #17900
Teach `cmake_minimum_required` and `cmake_policy(VERSION)` to support a
version range of the form `<min>[...<max>]`. Define this to mean that
version `<min>` is required, but known policies up to those introduced
by `<max>` will be set to `NEW`. This will allow projects to easily
specify a range of versions for which they have been updated.
* Change some functions to take `std::string` instead of
`const char*` in the following classes: `cmMakeFile`, `cmake`,
`cmCoreTryCompile`, `cmSystemTools`, `cmState`, `cmLocalGenerator`
and a few others.
* Greatly reduce using of `const char*` overloads for
`cmSystemTools::MakeDirectory` and `cmSystemTools::RelativePath`.
* Remove many redundant `c_str()` conversions throughout the code.
e6a80ccf Make use of std::chrono throughout every component
ff62b005 CTest: add safe conversion from cmDuration to integer types
695951bc CTest: introduce cmDuration
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1592
This commit continues the changes made in CTest to support std::chrono
by
applying it throughout every component where a duration was used.
No functional change intended.
