CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-03-28T15:15:57-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/23910CPack: WiX 4 support2024-03-28T15:15:57-04:00Ben BoeckelCPack: WiX 4 supportInvestigating WiX 4 in order to avoid WiX 3's lacking support of Windows longpaths (`\\?\` prefixes). However, the previews do not provide `candle` or `light`. I'm not sure what exactly replaces them as I haven't found release notes.
/c...Investigating WiX 4 in order to avoid WiX 3's lacking support of Windows longpaths (`\\?\` prefixes). However, the previews do not provide `candle` or `light`. I'm not sure what exactly replaces them as I haven't found release notes.
/cc @brad.king3.30.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16033WiX 4.x might require new XML namespace2024-03-24T15:25:38-04:00Kitware RobotWiX 4.x might require new XML namespaceThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=16033). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=16033). Further discussion may take place here.Nils GladitzNils Gladitzhttps://gitlab.kitware.com/cmake/cmake/-/issues/23351Use domains by default for productbuild CPack generator2024-02-06T15:00:33-05:00Craig ScottUse domains by default for productbuild CPack generatorSplitting out a separate issue for the policy mentioned in https://gitlab.kitware.com/cmake/cmake/-/issues/23030#note_1160326. We should default `CPACK_PRODUCTBUILD_DOMAINS` to true, which means a policy is needed since it defaults to fa...Splitting out a separate issue for the policy mentioned in https://gitlab.kitware.com/cmake/cmake/-/issues/23030#note_1160326. We should default `CPACK_PRODUCTBUILD_DOMAINS` to true, which means a policy is needed since it defaults to false at the moment (it was added in CMake 3.23).3.29.0Craig ScottCraig Scotthttps://gitlab.kitware.com/cmake/cmake/-/issues/25421CPack/RPM: Broken with rpm 4.192024-02-01T05:20:10-05:00Sergei GolubchikCPack/RPM: Broken with rpm 4.19In Fedora39 new RPM 4.19.0 comes in. It includes this commit: https://github.com/rpm-software-management/rpm/commit/d44114f007f54f205ffa13d22724199fe50a137a
It unfortunately conflicts with how CPackRPM lists files in the `%files` sectio...In Fedora39 new RPM 4.19.0 comes in. It includes this commit: https://github.com/rpm-software-management/rpm/commit/d44114f007f54f205ffa13d22724199fe50a137a
It unfortunately conflicts with how CPackRPM lists files in the `%files` section: they are unconditionally double-quoted and an asterisk is unconditionally appended to all man pages. As a result, the following section of MariaDB-backup specs file:
```plaintext
%files
%defattr(-,root,root,-)
"/usr/bin/mariabackup"
"/usr/bin/mariadb-backup"
"/usr/bin/mbstream"
"/usr/share/man/man1/mariabackup.1*"
"/usr/share/man/man1/mariadb-backup.1*"
"/usr/share/man/man1/mbstream.1*"
```
is interpreted literally and naturally the build fails with
```plaintext
error: File not found: .../build/_CPack_Packages/Linux/RPM/mariadb-11.1.3-linux-x86_64/backup/usr/share/man/man1/mariabackup.1\*
```3.28.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/23030CPack/productbuild: pkg-ref "auth" attribute not configurable in Distributio...2024-01-28T02:13:05-05:00David WoskCPack/productbuild: pkg-ref "auth" attribute not configurable in Distribution.xmlWhen using the `productbuild` generator, the `Distribution.xml` file that is generated contains a `pkg-ref` element with `auth="Admin"` attribute like so:
```xml
<pkg-ref id="foo" version="1.0.0" installKBytes="191782" auth="Admin" onCon...When using the `productbuild` generator, the `Distribution.xml` file that is generated contains a `pkg-ref` element with `auth="Admin"` attribute like so:
```xml
<pkg-ref id="foo" version="1.0.0" installKBytes="191782" auth="Admin" onConclusion="None">file:./Contents/Packages/foo.pkg</pkg-ref>
```
This ends up causing the PKG to request admin privileges during install even when the product is only allowed to be installed in the user's home directory via:
```xml
<domains enable_currentUserHome=\"true\" enable_localSystem=\"false\"/>\
```
This `auth` attribute does not appear configurable via CPack (hardcoded in the generator). It's been marked as deprecated by Apple (in favor of `domains`) so if it's not going to be removed (maybe for b/w compatibility?) it would be nice if it were configurable somehow.
FWIW, I'm attempting to build a PKG that can be installed in either the root directory (`/Applications`) or the user's home directory (`~/Applications`). I'm able to workaround this issue by placing my own `CPack.distribution.dist.in` file in the CMake module path, removing `@CPACK_PACKAGEMAKER_CHOICES@`, and explicitly specifying the component groups myself (minus the `auth="Admin"`). Works as expected afterwards, however, this is less than ideal.
If there's another way to do it, LMK.https://gitlab.kitware.com/cmake/cmake/-/issues/25634CPack/WiX: Windows installer status strings broken2024-01-25T10:33:15-05:00Mark WatermanCPack/WiX: Windows installer status strings brokenProgress messages in the Windows installer are only displaying a format string in recent versions of Windows:
![cmake_installer](/uploads/34a1048e6a4237010f3df89bccf3deed/cmake_installer.png)
This is a known issue with WIX that started...Progress messages in the Windows installer are only displaying a format string in recent versions of Windows:
![cmake_installer](/uploads/34a1048e6a4237010f3df89bccf3deed/cmake_installer.png)
This is a known issue with WIX that started with the Windows 10 Creators Update, circa 2017. Should be easy to fix: add the following element under the WIX script's <Product> tag:
`<UIRef Id="WixUI_ErrorProgressText" />`
See also: https://stackoverflow.com/questions/44161526/wix-copying-new-files-file-1-directory-9-size-6-shown-during-instal3.29.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25615CPack/RPM: [PATCH] Fix CPACK_THREADS variable usage2024-01-24T08:39:59-05:00Elijah ZarezkyCPack/RPM: [PATCH] Fix CPACK_THREADS variable usage```
diff -up cmake-3.27.9/Modules/Internal/CPack/CPackRPM.cmake.orig cmake-3.27.9/Modules/Internal/CPack/CPackRPM.cmake
--- cmake-3.27.9/Modules/Internal/CPack/CPackRPM.cmake.orig 2023-11-28 17:52:37.000000000 +0300
+++ cmake-3.27.9/Modu...```
diff -up cmake-3.27.9/Modules/Internal/CPack/CPackRPM.cmake.orig cmake-3.27.9/Modules/Internal/CPack/CPackRPM.cmake
--- cmake-3.27.9/Modules/Internal/CPack/CPackRPM.cmake.orig 2023-11-28 17:52:37.000000000 +0300
+++ cmake-3.27.9/Modules/Internal/CPack/CPackRPM.cmake 2024-01-18 11:00:25.592770537 +0300
@@ -1031,7 +1031,11 @@ function(cpack_rpm_generate_package)
set(CPACK_RPM_COMPRESSION_TYPE_TMP "%define _binary_payload w9.lzdio")
endif()
if(CPACK_RPM_COMPRESSION_TYPE STREQUAL "xz")
- set(CPACK_RPM_COMPRESSION_TYPE_TMP "%define _binary_payload w7.xzdio")
+ if(CPACK_THREADS GREATER "0")
+ set(CPACK_RPM_COMPRESSION_TYPE_TMP "%define _binary_payload w7T${CPACK_THREADS}.xzdio")
+ else()
+ set(CPACK_RPM_COMPRESSION_TYPE_TMP "%define _binary_payload w7T.xzdio")
+ endif()
endif()
if(CPACK_RPM_COMPRESSION_TYPE STREQUAL "bzip2")
set(CPACK_RPM_COMPRESSION_TYPE_TMP "%define _binary_payload w9.bzdio")
```3.29.0https://gitlab.kitware.com/cmake/cmake/-/issues/25545CPack RPM can't deal with man pages properly, as it is not able to find them ...2024-01-16T11:24:41-05:00Raffaello BertiniCPack RPM can't deal with man pages properly, as it is not able to find them because rpmbuild compressed themwhen running cpack for RPM including some man pages files in a directory,
rpmbuild will compress them and remove the original files,
this will mismatch with the generated spec file that can't find the files.
besides the generated spe...when running cpack for RPM including some man pages files in a directory,
rpmbuild will compress them and remove the original files,
this will mismatch with the generated spec file that can't find the files.
besides the generated spec looks almost correct:
```rpmspec
%dir "/usr/share/man"
%dir "/usr/share/man/man1"
"/usr/share/man/man1/myapp.1*"
```
the content in that folder instead of having files in the `myapp.1` folder, there is the compressed file, `myapp.1.gz` in my case.
the output resulting is:
```
error: File not found: [...]/usr/share/man/man1/myapp.1\*
```
The fix is to replace the `"/usr/share/man/man1/myapp.1*"` with: `%{_mandir}/man1/myapp.1*`
when CPackRPM generates the spec filehttps://gitlab.kitware.com/cmake/cmake/-/issues/25542CPack: Missing the 'PackageReadmeFile' property in nuget generator2024-01-09T09:59:26-05:00Jan WilmansCPack: Missing the 'PackageReadmeFile' property in nuget generatornuget.org warns if a readme is not specified in the nuget package. It _should_ look like:
`<readme>my_readme_inside_the_package.md</readme>`
either the implementation could be very similar to #23703 or we can consider introducing an ex...nuget.org warns if a readme is not specified in the nuget package. It _should_ look like:
`<readme>my_readme_inside_the_package.md</readme>`
either the implementation could be very similar to #23703 or we can consider introducing an extension point by either:
* having a way to specify your own `.nuspec` file instead of the [hardcoded](https://gitlab.kitware.com/cmake/cmake/-/blob/066ff258dbea32cda233109910606c617fedc59f/Modules/Internal/CPack/CPackNuGet.cmake#L326) one.
* having a way to add user defined properties the "metadata" section
This way we do not have to support every property ever in cpack but instead let projects roll their own.
references:
* https://learn.microsoft.com/en-us/nuget/create-packages/package-authoring-best-practices#readmehttps://gitlab.kitware.com/cmake/cmake/-/issues/23703CPack NuGet configuration misses "repository" tag2024-01-09T09:59:26-05:00mohandarsiCPack NuGet configuration misses "repository" tagThere is no way to specify repository tag with [CPACK](https://cmake.org/cmake/help/latest/cpack_gen/nuget.html) (Variables to CPack NuGet generator) which deviates from current [nuspec specification](https://docs.microsoft.com/en-us/nug...There is no way to specify repository tag with [CPACK](https://cmake.org/cmake/help/latest/cpack_gen/nuget.html) (Variables to CPack NuGet generator) which deviates from current [nuspec specification](https://docs.microsoft.com/en-us/nuget/reference/nuspec).
Add/support following or similar tags
```
set(CPACK_NUGET_PACKAGE_REPOSITORY_TYPE "git")
set(CPACK_NUGET_PACKAGE_REPOSITORY_URL "https://github.com/this_repository")
set(CPACK_NUGET_PACKAGE_REPOSITORY_BRANCH "<your_branch_here>")
set(CPACK_NUGET_PACKAGE_REPOSITORY_COMMIT "<your_hash_here>")
```
which should translate into
`<repository type="git" url="https://github.com/this_repository" branch="<your_branch_here>" commit="<your_hash_here>" />`https://gitlab.kitware.com/cmake/cmake/-/issues/25543CPACK_TEMPORARY_PACKAGE_FILE_NAME has incorrect value2024-01-08T10:51:29-05:00Jan WilmansCPACK_TEMPORARY_PACKAGE_FILE_NAME has incorrect value```
CPACK_PACKAGE_FILES=C:/project/example/nuget/build/_CPack_Packages/win64/NuGet/example-1.0.2-win64/example.1.0.2.nupkg << Correct!
CPACK_TEMPORARY_INSTALL_DIRECTORY=C:/project/example/nuget/build/_CPack_Packages/win64/NuGet/example-1...```
CPACK_PACKAGE_FILES=C:/project/example/nuget/build/_CPack_Packages/win64/NuGet/example-1.0.2-win64/example.1.0.2.nupkg << Correct!
CPACK_TEMPORARY_INSTALL_DIRECTORY=C:/project/example/nuget/build/_CPack_Packages/win64/NuGet/example-1.0.2-win64 << Correct!
CPACK_TEMPORARY_PACKAGE_FILE_NAME=C:/project/example/nuget/build/_CPack_Packages/win64/NuGet/example-1.0.2-win64.nupkg << Not Correct!
```
The temporary nupkg file is generated as `C:/project/example/nuget/build/_CPack_Packages/win64/NuGet/example-1.0.2-win64/example-1.0.2-win64.nupkg`, despite the CPACK_TEMPORARY_PACKAGE_FILE_NAME missing the extra `/example-1.0.2-win64/` level.https://gitlab.kitware.com/cmake/cmake/-/issues/25280CPack: Archive generation repeats duplicate files files across components2023-10-27T09:07:53-04:00Atilhan Emre DursunogluCPack: Archive generation repeats duplicate files files across componentsIn our monorepo, for every target we create a component for executable/shared library itself and another component for its runtime dependencies. We are doing runtime dependency installation via `install(RUNTIME_DEPENDENCY_SET)`. This is ...In our monorepo, for every target we create a component for executable/shared library itself and another component for its runtime dependencies. We are doing runtime dependency installation via `install(RUNTIME_DEPENDENCY_SET)`. This is great for us as it brings us a great granularity, we can easily mix and match different components into a cpack script and using `ALL_COMPONENTS_IN_ONE` we can generate one big release file. However downside of this is most of our projects use mostly the same dependencies, and CPacks's Archive Generator doesn't differentiate same files of different components, thus our archive generation takes unnecessary long and the release file gets unnecessary big.
This proposal aims to introduce a file deduplication mechanism exclusively for CPack's archive generation (.tgz, .7z, etc.) when consolidating multiple components into a single archive. The deduplication feature is not extended to installer generation methods like qt, nsis, etc. After components are installed, in package creation phase, system will track every path added to the archive and if a path that matches one already in the archive, the content is checked against the stored version, if contents differ then should raise an error, otherwise we do not add the path to the archive again. This feature's flags are `CPACK_ARCHIVE_DEDUPLICATE` which will be applied if `CPACK_COMPONENTS_GROUPING` is set to ALL_COMPONENTS_IN_ONE and `CPACK_ARCHIVE_<group>_DEDUPLICATE` which the setting applies only to the specified component group. This feature is specifically designed for scenarios where a single archive is created from multiple components.
Thanks to this system, our packaging times are down from 1m30,359s to 0m23,434s. The file sizes shrank too, from 850 MB to 124 MB.https://gitlab.kitware.com/cmake/cmake/-/issues/13939NSIS installer doesn't honor standard user permission2023-09-06T11:19:10-04:00Kitware RobotNSIS installer doesn't honor standard user permissionThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13939). Further discussion may take place here.
---
When installing an NSIS package generated by CMake as a standard user, the insta...This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13939). Further discussion may take place here.
---
When installing an NSIS package generated by CMake as a standard user, the installer tries to install the program into the "all users" location, which fails because of permissions. It should install into the user's directory.
The bug seems to have been introduced while fixing #12923 (commit c4a0bcea775981dea86d527f66161c98f5e05e95). Whereas the first correction from +3 to +4 was correct to enable the recognition of power users, the second change
```patch
- StrCmp $1 "Power" 0 +3
+ StrCmp $1 "Power" 0 +4
```
is wrong. It will jump to `StrCpy $SV_ALLUSERS "AllUsers"` instead of `Goto done` for a standard user. This change should be reverted.3.28.0https://gitlab.kitware.com/cmake/cmake/-/issues/25083InnoSetup: Marking a component as REQUIRED makes it disabled and not installable2023-07-18T10:30:12-04:00Craig ScottInnoSetup: Marking a component as REQUIRED makes it disabled and not installableConsider the following fairly minimal reproducer project:
```cmake
cmake_minimum_required(VERSION 3.27)
project(MyProj VERSION 1.3.29)
add_executable(MainApp main.cpp)
install(TARGETS MainApp COMPONENT Main)
set(CPACK_PACKAGE_NAME ...Consider the following fairly minimal reproducer project:
```cmake
cmake_minimum_required(VERSION 3.27)
project(MyProj VERSION 1.3.29)
add_executable(MainApp main.cpp)
install(TARGETS MainApp COMPONENT Main)
set(CPACK_PACKAGE_NAME MyProj)
set(CPACK_PACKAGE_VENDOR MyCompany)
set(CPACK_PACKAGE_DESCRIPTION_SUMMARY "Example Inno Setup project")
set(CPACK_PACKAGE_INSTALL_DIRECTORY "${CPACK_PACKAGE_NAME}")
set(CPACK_PACKAGE_VERSION_MAJOR ${PROJECT_VERSION_MAJOR})
set(CPACK_PACKAGE_VERSION_MINOR ${PROJECT_VERSION_MINOR})
set(CPACK_PACKAGE_VERSION_PATCH ${PROJECT_VERSION_PATCH})
set(CPACK_VERBATIM_VARIABLES YES)
set(CPACK_GENERATOR INNOSETUP)
include(CPack)
cpack_add_component(Main REQUIRED)
```
If you build that project and run `cpack` in the build directory, it will produce a valid installer. If you then try to install that package, the dialog presented to you will show the `Main` component, but it will be both unchecked and disabled. The result is that the `Main` component cannot be installed, even though it has been marked as `REQUIRED`.3.27.0https://gitlab.kitware.com/cmake/cmake/-/issues/22635CPack/RPM: Issue with CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX variable2023-05-08T13:36:08-04:00Laurent MalkaCPack/RPM: Issue with CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX variableThere seems to be an issue with the `CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX` variable not working as intended.
With the following code:
```cmake
cmake_minimum_required(VERSION 3.21)
project(cpack_example)
install(FILES foo.h
DESTINATI...There seems to be an issue with the `CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX` variable not working as intended.
With the following code:
```cmake
cmake_minimum_required(VERSION 3.21)
project(cpack_example)
install(FILES foo.h
DESTINATION lib
COMPONENT FOO
)
install(FILES bar.h
DESTINATION bin
COMPONENT BAR
)
set(CPACK_RPM_PACKAGE_RELOCATABLE ON)
set(CPACK_PACKAGE_NAME Example)
set(CPACK_PACKAGE_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/package)
set(CPACK_GENERATOR RPM)
set(CPACK_COMPONENTS_GROUPING ONE_PER_GROUP)
set(CPACK_RPM_COMPONENT_INSTALL ON)
set(CPACK_RPM_FOO_PACKAGE_PREFIX "/usr")
set(CPACK_RPM_BAR_PACKAGE_PREFIX "/etc")
include(CPack)
cpack_add_component(FOO
DISPLAY_NAME FOO
REQUIRED
)
cpack_add_component(BAR
DISPLAY_NAME BAR
REQUIRED
)
```
The packaging gives the following output:
```
❯ cmake --build . --target package
[0/1] Run CPack packaging tool...
CPack: Create package using RPM
CPack: Install projects
CPack: - Install project: cpack_example []
CPack: - Install component: BAR
CPack: - Install component: FOO
CPack: Create package
-- alien found, we may be on a Debian based distro.
CMake Warning (dev) at /home/lmalka/bin/cmake-3.21.1-linux-x86_64/share/cmake-3.21/Modules/Internal/CPack/CPackRPM.cmake:190 (message):
CPackRPM:Warning: Path /usr/bin/bar.h is not on one of the relocatable
paths! Package will be partially relocatable.
Call Stack (most recent call first):
/home/lmalka/bin/cmake-3.21.1-linux-x86_64/share/cmake-3.21/Modules/Internal/CPack/CPackRPM.cmake:1058 (cpack_rpm_prepare_relocation_paths)
/home/lmalka/bin/cmake-3.21.1-linux-x86_64/share/cmake-3.21/Modules/Internal/CPack/CPackRPM.cmake:1958 (cpack_rpm_generate_package)
This warning is for project developers. Use -Wno-dev to suppress it.
CPackRPM: Will use GENERATED spec file: /home/lmalka/dev/tests/cpack_example/build/package/_CPack_Packages/Linux/RPM/SPECS/example-BAR.spec
-- alien found, we may be on a Debian based distro.
CPackRPM: Will use GENERATED spec file: /home/lmalka/dev/tests/cpack_example/build/package/_CPack_Packages/Linux/RPM/SPECS/example-FOO.spec
CPack: - package: /home/lmalka/dev/tests/cpack_example/build/package/Example-0.1.1-Linux-BAR.rpm generated.
CPack: - package: /home/lmalka/dev/tests/cpack_example/build/package/Example-0.1.1-Linux-FOO.rpm generated.
```
Installing the `FOO` package works as intended and copies the foo.h file to `/usr/lib`, but installing the `BAR` package does nothing.
Here are some information about the generated `.rpm` files:
```
❯ rpm -qi package/Example-0.1.1-Linux-FOO.rpm
Name : example-FOO
Version : 0.1.1
Release : 1
Architecture: x86_64
Install Date: (not installed)
Group : unknown
Size : 0
License : unknown
Signature : (none)
Source RPM : example-FOO-0.1.1-1.src.rpm
Build Date : Tue 14 Sep 2021 10:42:23 AM CEST
Build Host : lmalka-mint
Relocations : /usr
Vendor : Humanity
Summary : cpack_example built using CMake
Description :
DESCRIPTION
===========
This is an installer created using CPack (https://cmake.org). No additional installation instructions provided.
❯ rpm -qi package/Example-0.1.1-Linux-BAR.rpm
Name : example-BAR
Version : 0.1.1
Release : 1
Architecture: x86_64
Install Date: (not installed)
Group : unknown
Size : 0
License : unknown
Signature : (none)
Source RPM : example-BAR-0.1.1-1.src.rpm
Build Date : Tue 14 Sep 2021 10:42:23 AM CEST
Build Host : lmalka-mint
Relocations : (not relocatable)
Vendor : Humanity
Summary : cpack_example built using CMake
Description :
DESCRIPTION
===========
This is an installer created using CPack (https://cmake.org). No additional installation instructions provided.
```
If I understand the documentation correctly, the `BAR` package should have `/opt` in its relocations paths, which is not the case.https://gitlab.kitware.com/cmake/cmake/-/issues/24085CPack --trace and --trace-expand options expect arguments since 3.24.02022-10-27T09:29:18-04:00Ben AppletonCPack --trace and --trace-expand options expect arguments since 3.24.0
CMake was recently upgraded to from `3.16.3` to `3.24.2` on a machine that I use for CI.
There is a packaging process that uses `cpack`, invoked with `cpack --trace --verbose`. Since the upgrade this call has failed, claiming `--trace`...
CMake was recently upgraded to from `3.16.3` to `3.24.2` on a machine that I use for CI.
There is a packaging process that uses `cpack`, invoked with `cpack --trace --verbose`. Since the upgrade this call has failed, claiming `--trace` option needs an argument.
Below are some examples of expected and observed behaviour when invoking `cpack --trace` (note cpack is expected to fail due to invalid configuration)
# Examples
## Output prior to upgrade
cpack fails (expected, due to no generator) but trace is emitted:
```zsh
~ cmake --version
cmake version 3.16.3
CMake suite maintained and supported by Kitware (kitware.com/cmake).
~ cpack --version
cpack version 3.16.3
CMake suite maintained and supported by Kitware (kitware.com/cmake).
~ cpack --trace
/usr/local/share/cmake-3.16/Modules/CMakeDetermineSystem.cmake(34): if(CMAKE_HOST_UNIX )
/usr/local/share/cmake-3.16/Modules/CMakeDetermineSystem.cmake(35): find_program(CMAKE_UNAME uname /bin /usr/bin /usr/local/bin )
***** [ OMITTED FOR BREVITY ] *****
/usr/local/share/cmake-3.16/Modules/CMakeSystemSpecificInformation.cmake(54): set(CMAKE_SHARED_MODULE_SUFFIX ${CMAKE_SHARED_LIBRARY_SUFFIX} )
/usr/local/share/cmake-3.16/Modules/CMakeSystemSpecificInformation.cmake(58): set(CMAKE_SYSTEM_SPECIFIC_INFORMATION_LOADED 1 )
CPack Error: CPack generator not specified
```
## Output after upgrade
cpack fails when parsing command line, compains about --trace
```zsh
~ cmake --version
cmake version 3.24.2
CMake suite maintained and supported by Kitware (kitware.com/cmake).
~ cpack --version
cpack version 3.24.2
CMake suite maintained and supported by Kitware (kitware.com/cmake).
~ cpack --trace
CMake Error: Invalid value used with --trace
```
## Output after upgrade with workaround
```zsh
~ cpack --version
cpack version 3.16.3
CMake suite maintained and supported by Kitware (kitware.com/cmake).
~ cpack --trace any_old_string
/usr/local/Cellar/cmake/3.24.2/share/cmake/Modules/CMakeDetermineSystem.cmake(35): if(CMAKE_HOST_UNIX )
/usr/local/Cellar/cmake/3.24.2/share/cmake/Modules/CMakeDetermineSystem.cmake(36): find_program(CMAKE_UNAME uname /bin /usr/bin /usr/local/bin )
***** [ OMITTED FOR BREVITY ] *****
/usr/local/share/cmake-3.16/Modules/CMakeSystemSpecificInformation.cmake(58): set(CMAKE_SYSTEM_SPECIFIC_INFORMATION_LOADED 1 )
CPack Error: CPack generator not specified
```
# Possible cause
The commit [`87c762d435470ef50d1c9ee14f1b34aaf0a84767`](https://gitlab.kitware.com/cmake/cmake/-/commit/87c762d435470ef50d1c9ee14f1b34aaf0a84767) may have introduced this issue.
Prior to the commit, the `--trace` argument in `Source/CPack/cpack.cxx` takes no arguments:
```c++
arg.AddArgument("--trace", argT::NO_ARGUMENT, &trace,
"Put underlying cmake scripts in trace mode.");
```
[See line in commit](https://gitlab.kitware.com/cmake/cmake/-/commit/87c762d435470ef50d1c9ee14f1b34aaf0a84767#b6a894ee656556f8ac547e5655a3e545f1e21b6a_171_119)
After the commit, the `--trace` argument takes a single argument:
```c++
CommandArgument{ "--trace", CommandArgument::Values::One, traceLambda },
```
[See line in commit](https://gitlab.kitware.com/cmake/cmake/-/commit/87c762d435470ef50d1c9ee14f1b34aaf0a84767#b6a894ee656556f8ac547e5655a3e545f1e21b6a_207_168)
The `traceLambda` function explicitly ignores the command argument [function](https://gitlab.kitware.com/cmake/cmake/-/commit/87c762d435470ef50d1c9ee14f1b34aaf0a84767#b6a894ee656556f8ac547e5655a3e545f1e21b6a_207_135)Kyle EdwardsKyle Edwardshttps://gitlab.kitware.com/cmake/cmake/-/issues/17724Enable HiDPI support in CPack-generated NSIS-based installers2022-10-21T10:13:02-04:00Alexander ShaduriEnable HiDPI support in CPack-generated NSIS-based installersCurrently the CPack-generated NSIS-based installers are all blurry when run on a HiDPI display. Please allow specifying the ManifestDPIAware option through CPack variables
http://nsis.sourceforge.net/Reference/ManifestDPIAware
ThanksCurrently the CPack-generated NSIS-based installers are all blurry when run on a HiDPI display. Please allow specifying the ManifestDPIAware option through CPack variables
http://nsis.sourceforge.net/Reference/ManifestDPIAware
Thankshttps://gitlab.kitware.com/cmake/cmake/-/issues/21318CPack NSIS generator with Unicode support2022-09-25T15:07:06-04:00XiaofengCPack NSIS generator with Unicode supportUnicode is supported since NSIS 3.0, what about to turn on this feature by default in [NSIS.template.in](Modules/Internal/CPack/NSIS.template.in)?
https://nsis.sourceforge.io/Docs/Chapter1.html#intro-unicodeUnicode is supported since NSIS 3.0, what about to turn on this feature by default in [NSIS.template.in](Modules/Internal/CPack/NSIS.template.in)?
https://nsis.sourceforge.io/Docs/Chapter1.html#intro-unicode3.20.0https://gitlab.kitware.com/cmake/cmake/-/issues/23889CPack: Impossible to produce IPA file (iOS/tvOS) out of the box2022-09-07T09:44:23-04:00Andrey FilipenkovCPack: Impossible to produce IPA file (iOS/tvOS) out of the boxIPA is a standard format to distribute iOS/tvOS apps which is just a zip with special structure: basically the built .app bundle is placed in `Payload` directory and then this directory is zipped.
Creating such zip file with CPack is al...IPA is a standard format to distribute iOS/tvOS apps which is just a zip with special structure: basically the built .app bundle is placed in `Payload` directory and then this directory is zipped.
Creating such zip file with CPack is already possible (see example [here](https://github.com/kambala-decapitator/vcmi/commit/c58789d58c087ae92f5c2e6b4d1bea041060b155)), but there's no way to give it a custom extension, so I have to perform renaming with an additional script.
Adding new CPack variable that allows specifying custom archive extension (e.g. `CPACK_ARCHIVE_OUTPUT_EXTENSION`) would solve this.https://gitlab.kitware.com/cmake/cmake/-/issues/23117presets: Add "package" presets for cpack2022-09-02T09:04:17-04:00Brad Kingpresets: Add "package" presets for cpackWe have configure (`cmake`), build (`cmake --build`), and test (`ctest`) presets. It might make sense to have presets for `cpack` too.We have configure (`cmake`), build (`cmake --build`), and test (`ctest`) presets. It might make sense to have presets for `cpack` too.