| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
When mention execitable names use Sphinx semantic role `:program`
instead of ``executable`` or **executable**.
|
|
|
|
|
| |
Previously this requirement was only mentioned in the 3.20 release
notes.
|
|
|
|
|
|
|
|
| |
`CMakeFindBinUtils.cmake` sets `CMAKE_<TOOL>` variables that in
cross-compilation environments point to the toolchain specific
executables: e.g. `CMAKE_OBJCOPY` might point to
`<path_to_toolchain>/arm-poky-linux-gnueabi-objcopy`.
Pass this information to CPack.
|
| |
|
|
|
|
|
|
| |
This CPack generator has been deprecated since commit 7bf187499f
(CPack: Deprecate PackageMaker generator, 2020-01-31).
Fixes: #23344
|
|
|
|
|
|
|
|
| |
Since macOS 12.0 deprecated the tools needed to attach a SLA to a
`.dmg`, we should no longer do this by default. Add a policy to
change the default to off.
Fixes: #22978
|
| |
|
|
|
|
| |
Prepare to add more entries beyond `xz`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since macOS 12.0, the ``hdiutil udifrez`` and ``hdiutil udifderez``
commands to embed and extract resources in a disk image are deprecated.
The CPack DragNDrop Generator uses these to attach the SLA specified by
the `CPACK_RESOURCE_FILE_LICENSE` option. Since that option is shared
by multiple CPack generators, we cannot deprecate it. Instead, add an
explicit option to control the behavior. This will give projects a way
to package on future macOS versions that remove the commands.
In order to provide a long-term transition away from attaching SLAs to
disk images, update `cpack` to default this behavior to OFF. To retain
compatibility for CMake projects, teach the CPack module to default the
option to ON. Later a policy can be added to change the default.
Issue: #22978
|
|
|
|
|
|
|
|
| |
This CPack generator was never documented, and has been deprecated since
commit 2ed00e8ef8 (CPack: Deprecate OSXX11 generator, 2020-01-31,
v3.17.0-rc1~45^2).
Issue: #20235
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
This allows setting how many threads the compressor will use.
Currently only implemented for XZ when using system's lzma library.
Fixes: #21715
|
|
|
|
| |
Issue: #19715
|
|
|
| |
Relates: #19077
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See https://github.com/codespell-project/codespell#readme
The following command was used:
```
codespell -q6 --skip="\
.git,\
*.json,\
./Copyright.txt,\
./Help/command/foreach.rst,\
./Help/prop_test/REQUIRED_FILES.rst,\
./Help/variable/CTEST_COVERAGE_COMMAND.rst,\
./Modules/CMakeCheckCompilerFlagCommonPatterns.cmake,\
./Modules/CMakeRCInformation.cmake,\
./Modules/Internal/CPack/NSIS.template.in,\
./Modules/FindMatlab.cmake,\
./Modules/MatlabTestsRedirect.cmake,\
./Modules/Platform/Windows-Clang.cmake,\
./Modules/Platform/Windows-Intel-Fortran.cmake,\
./Modules/Platform/Windows-MSVC.cmake,\
./Source/CMakeVersion.cmake,\
./Source/cmConvertMSBuildXMLToJSON.py,\
./Source/cmCreateTestSourceList.cxx,\
./Source/cmGlobalVisualStudio10Generator.cxx,\
./Source/cmExportBuildFileGenerator.cxx,\
./Source/cmExportInstallAndroidMKGenerator.cxx,\
./Source/cmExportInstallFileGenerator.cxx,\
./Source/cmExportSet.cxx,\
./Source/cmExportTryCompileFileGenerator.cxx,\
./Source/cmFindPackageCommand.cxx,\
./Source/cmInstallCommand.cxx,\
./Source/cmGeneratorExpressionLexer.cxx,\
./Source/cmLocalVisualStudio7Generator.cxx,\
./Source/cmOrderDirectories.cxx,\
./Source/cmTarget.cxx,\
./Source/kwsys/*,\
./Source/QtDialog/CMakeSetupDialog.ui,\
./Source/CPack/WiX/cmWIXRichTextFormatWriter.cxx,\
./Source/CTest/cmParseCoberturaCoverage.h,\
./Tests/CMakeTests/ImplicitLinkInfoTest.cmake.in,\
./Tests/RunCMake/CPack/tests/DMG_SLA/English.license.rtf,\
./Tests/RunCMake/CPack/tests/DMG_SLA/German.license.txt,\
./Tests/RunCMake/CPack/tests/DMG_SLA/German.menu.txt,\
./Tests/RunCMake/GoogleTest/xml_output.cpp,\
./Tests/RunCMake/Make/TargetMessages*,\
./Utilities/*,\
" \
-L "\
dependees,\
endwhile,\
fo,\
filetest,\
helpfull,\
nd,\
objext,\
stoll,\
supercedes,\
superceded,\
vas,\
varn,\
"
```
|
|\
| |
| |
| |
| |
| |
| | |
ca9bd43f2d Help: Duplicate essential information on install paths in CPack.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4987
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| | |
f8b7acaf90 Help: Fix CPack module docs on config file for source package
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4985
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
We already have a `.. _targets:` in `Help/command/install.rst`.
|
|
|
|
|
| |
To explain in full detail to what extent the targets package and
package_source are supported by different generators.
|
| |
|
|
|
|
|
| |
Explain the usage of the two new build targets, package and
package_source.
|
|
|
|
| |
Besides CPackConfig.cmake, the module also generates CPackSourceConfig.cmake.
|
|
|
|
|
| |
Including CPack does not "build" installers.
It just *configures* them.
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Xcode no longer distributes the PackageMaker tools.
Add a deprecation warning when the generator is used.
Issue: #20235
|
|\
| |
| |
| |
| |
| |
| | |
baec299ecd CPack: Fix regression in Deb description
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4271
|
| |
| |
| |
| | |
Fixes: #20254
|
| | |
|
|\ \
| |/
| |
| |
| |
| |
| | |
d491f34a5e CPack: Fix regression in DEB generator description
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4204
|
| |
| |
| |
| | |
Fixes: #20102
|
|\ \
| |/
| |
| |
| |
| |
| |
| | |
1d1fa5d3e4 Tests: Add RunCMake.CPackCommandLine case for multi-config package
108207cc84 CPack: Remove CPACK_INSTALL_CMAKE_CONFIGURATIONS
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4025
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|/
|
|
| |
Fixes: #10728
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
The one extant section header was confusing at least:
Not all the doc page is on Variables.
|
|
|
|
|
|
|
|
| |
Apple's main Operating system changed their name from OS X to macOS:
https://www.engadget.com/2016/06/13/os-x-is-now-macos/
Revise documentation accordingly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Also indent variable docs consistently.
|
| |
|
| |
|
|
|
|
| |
Use `#[===...==[.rst:` comments for docs.
|