CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2020-12-08T10:29:37-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/17339CPackDeb: Debian package version must not contain hyphens when CPACK_DEBIAN_P...2020-12-08T10:29:37-05:00Jason JuangCPackDeb: Debian package version must not contain hyphens when CPACK_DEBIAN_PACKAGE_RELEASE is not provided!I am on Ubuntu 16.04 latest CMake. With the recent change of CPack, setting `CPACK_PACKAGE_VERSION` alone becomes insufficient and it shows the compilation error
``````
CPackDeb: Debian package version must not contain hyphens when
C...I am on Ubuntu 16.04 latest CMake. With the recent change of CPack, setting `CPACK_PACKAGE_VERSION` alone becomes insufficient and it shows the compilation error
``````
CPackDeb: Debian package version must not contain hyphens when
CPACK_DEBIAN_PACKAGE_RELEASE is not provided!
``````
I simply set the `CPACK_PACKAGE_VERSION` to {Latest Release}-{Number of commit after latest release}-{Current commit hash}. Using tinyxml2 as an example, it will be 5.0.1-71-g884852e. However, when I look at https://cmake.org/cmake/help/v3.10/module/CPackDeb.html it is unclear what `CPACK_DEBIAN_PACKAGE_RELEASE` is supposed to be set to. I tried setting `CPACK_DEBIAN_PACKAGE_RELEASE` also to {Latest Release}-{Number of commit after latest release}-{Current commit hash} but it gives me a new error
``````
CPackDeb: Debian package release must confirm to "^[A-Za-z0-9.+~]+$" regex!
``````
and I have no idea what this means. Can someone tell me what I am suppose to put for `CPACK_DEBIAN_PACKAGE_RELEASE` to make it work again?
Below is the complete step by step to reproduce the problem in latest CMake but work with CMake 3.9.2.
``````
git clone https://github.com/leethomason/tinyxml2
cd tinyxml2
echo '\n' >> CMakeLists.txt
echo 'set(CPACK_GENERATOR "DEB")' >> CMakeLists.txt
echo 'set(CPACK_DEBIAN_PACKAGE_MAINTAINER "Jason Juang")' >> CMakeLists.txt
echo 'execute_process(COMMAND bash "-c" "git describe --tags | sed s/[vV]//g" OUTPUT_VARIABLE GIT_TAG)' >> CMakeLists.txt
echo 'string(REGEX REPLACE "\\n$" "" GIT_TAG ${GIT_TAG})' >> CMakeLists.txt
echo 'set (CPACK_PACKAGE_VERSION ${GIT_TAG})' >> CMakeLists.txt
echo 'set (CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS ON)' >> CMakeLists.txt
echo 'set (CPACK_DEBIAN_PACKAGE_SHLIBDEPS ON)' >> CMakeLists.txt
echo 'set (CPACK_PACKAGE_NAME tinyxml2)' >> CMakeLists.txt
echo 'set (CPACK_PACKAGE_DESCRIPTION_SUMMARY "tinyxml2 built using CMake")' >> CMakeLists.txt
echo 'set (CPACK_DEBIAN_PACKAGE_DEBUG ON)' >> CMakeLists.txt
echo 'include(CPack)' >> CMakeLists.txt
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr -DBUILD_SHARED_LIBS=ON ..
make package
``````3.10.0Domen VrankarDomen Vrankarhttps://gitlab.kitware.com/cmake/cmake/-/issues/17328RunCMake.CPack_RPM RPM/DIST-MONOLITHIC-type subtest fails if RPM disttag cont...2017-10-30T09:07:25-04:00Petr PisarRunCMake.CPack_RPM RPM/DIST-MONOLITHIC-type subtest fails if RPM disttag contains a plusIf disttag RPM macro contains a "+" character, RunCMake.CPack_RPM RPM/DIST-MONOLITHIC-type subtest fails:
```
397: CMake Error at /builddir/build/BUILD/cmake-3.9.3/Tests/RunCMake/RunCMake.cmake:132 (message):
397: RPM/DIST-MONOLITHIC-...If disttag RPM macro contains a "+" character, RunCMake.CPack_RPM RPM/DIST-MONOLITHIC-type subtest fails:
```
397: CMake Error at /builddir/build/BUILD/cmake-3.9.3/Tests/RunCMake/RunCMake.cmake:132 (message):
397: RPM/DIST-MONOLITHIC-type - FAILED:
397:
397: Result is [1], not [0].
397:
397: stderr does not match that expected.
397:
397: Command was:
397:
397: command> "/builddir/build/BUILD/cmake-3.9.3/build/bin/cmake" "-DRunCMake_TEST=DIST-MONOLITHIC-type" "-DRunCMake_TEST_FILE_PREFIX=DIST" "-DRunCMake_SUBTEST_SUFFIX=" "-DGENERATOR_TYPE=RPM" "-DPACKAGING_TYPE=MONOLITHIC" "-Dsrc_dir=/builddir/build/BUILD/cmake-3.9.3/Tests/RunCMake/CPack" "-Dbin_dir=/builddir/build/BUILD/cmake-3.9.3/build/Tests/RunCMake/RPM/CPack/DIST-build" "-Dconfig_file=/builddir/build/BUILD/cmake-3.9.3/build/Tests/RunCMake/CPack/conf/RPM_config.cmake" "-P" "/builddir/build/BUILD/cmake-3.9.3/Tests/RunCMake/CPack/VerifyResult.cmake"
397:
397: Actual stdout:
397:
397: actual-out>
397:
397: Expected stderr to match:
397:
397: expect-err> ^(CPackRPM: Will use GENERATED spec file: (/[^/]*)*/Tests/RunCMake/RPM/CPack/[^-]*-build((-[^-]*-subtest/)|/)_CPack_Packages/.*/RPM/SPECS/[^\.]*\.spec(\n|$))*$
397:
397: Actual stderr:
397:
397: actual-err> CMake Error at /builddir/build/BUILD/cmake-3.9.3/Tests/RunCMake/CPack/tests/DIST/VerifyResult.cmake:10 (message):
397: actual-err> Unexpected Release in 'dist-0.1.1-Linux.rpm'; file info: 'Name : dist
397: actual-err>
397: actual-err> Version : 0.1.1
397: actual-err>
397: actual-err> Release : 1.module+36f4cc6b
397: actual-err>
397: actual-err> Architecture: x86_64
397: actual-err>
```
The subtest code is:
```
execute_process(COMMAND ${RPMBUILD_EXECUTABLE} -E %{?dist}
OUTPUT_VARIABLE DIST_TAG
ERROR_QUIET
OUTPUT_STRIP_TRAILING_WHITESPACE)
set(whitespaces_ "[\t\n\r ]*")
getPackageInfo("${FOUND_FILE_1}" "FILE_INFO_")
if(NOT FILE_INFO_ MATCHES ".*Release${whitespaces_}:${whitespaces_}1${DIST_TAG}")
message(FATAL_ERROR "Unexpected Release in '${FOUND_FILE_1}'; file info: '${FILE_INFO_}'")
endif()
```
It probably fails because the modular disttag contains plus "+" character and the value is used as a regular expression where plus is a metacharacter. The $DIST_TAG variable should be escaped against regular expression metacharacters. I tried Perl's \Q\E sequence, but looks like it's not supported.
I experience this issue with CMake 3.9.3. You can reproduce it with adding
```
%dist a+b
```
into a file in /usr/lib/rpm/macros.d/ directory (or where you rpmbuild loads macros from) and running the RunCMake.CPack_RPM test.3.10.0Domen VrankarDomen Vrankarhttps://gitlab.kitware.com/cmake/cmake/-/issues/17125CPackIFW doesn't work properly on OSX2017-09-27T17:54:19-04:00Michele CainiCPackIFW doesn't work properly on OSXAccording to the [documentation](http://doc.qt.io/qtinstallerframework/ifw-tools.html#binarycreator) for `binarycreator`, to create an offline installer the command line is:
<location-of-ifw>/binarycreator -t <location-of-ifw>/insta...According to the [documentation](http://doc.qt.io/qtinstallerframework/ifw-tools.html#binarycreator) for `binarycreator`, to create an offline installer the command line is:
<location-of-ifw>/binarycreator -t <location-of-ifw>/installerbase -p <package_directory> -c <config_directory>/<config_file> <installer_name>
In particular:
>On Mac, the target is created as an application bundle with the extension .app, which is automatically added, if not supplied. Additionally, you can specify the .dmg extension, which creates a DMG disk image that contains an .app bundle.
There are a few problems with that:
* We cannot set `CPACK_PACKAGE_FILE_NAME` to something like `<name>.dmg`, for `CPack` considers it as a package file name without extension. Therefore it keeps adding `.app` at the end of the string and creating a bundle. In other terms, there is no way to create a `.dmg` by means of `CPackIFW` on OSX. On the other side, that's one of the most interesting feature of IFW, so I would consider it a bug of the module.
[This](https://gitlab.kitware.com/cmake/cmake/blob/v3.9.0/Source/CPack/IFW/cmCPackIFWGenerator.cxx#L163) should be the offending code. At least, This is where the `<installer_name>` is appended to the command line to run `binarycreator`. I'm not sure where and how `.app` postfix is appended to `packageFileNames[0]` and I'm a bit busy to look over the whole code base of `CMake`, I'm sorry.
* The bundle isn't a file, it's a directory. Therefore, when `CPack` [tries to copy it over to the proper location](https://gitlab.kitware.com/cmake/cmake/blob/v3.9.0/Source/CPack/cmCPackGenerator.cxx#L1007), it simply creates an empty directory and doesn't copy anything. On Linux it copies the `.sh` file, on Windows it copies the `.exe` file, on OSX it creates an empty directory and that's all. It could be due to how `cmSystemTools::CopyFileIfDifferent` works, but it's just a guess.
Of course, the bundle is present within the `_CPack_Packages` tree, but we must run custom scripts to move it out of it somehow and create a `.dmg`.3.10.0Konstantin PodsvirovKonstantin Podsvirovhttps://gitlab.kitware.com/cmake/cmake/-/issues/16803Opt-in to new Win32 API that allows paths longer than 260 characters2017-10-18T10:23:30-04:00Taylor Braun-JonesOpt-in to new Win32 API that allows paths longer than 260 charactersCPack fails when packaging files in a deeply nested tree with total path length greater than 260 characters:
```
CPack Error: ERROR while packaging files: Error opening "some/long/filepath...": No such file or directory
```
Globally op...CPack fails when packaging files in a deeply nested tree with total path length greater than 260 characters:
```
CPack Error: ERROR while packaging files: Error opening "some/long/filepath...": No such file or directory
```
Globally opting in to the new Win32 API for the entire system fixes the problem (by enabling registry key `HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled` on Windows 10 build 1607 or newer) but CMake binaries should opt-in so this registry change is not necessary by enabling the `ws2:longPathAware` option in the manifest:
```xml
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
<ws2:longPathAware>true</ws2:longPathAware>
</windowsSettings>
</application>
```
Reference: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath
Note that this is somewhat counter to the proposal in #164853.10.0Brad KingBrad King