CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-03-25T14:24:56-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/25824CPACK_STRIP_FILES has no effect with relative CPACK_PACKAGING_INSTALL_PREFIX ...2024-03-25T14:24:56-04:00seemoritzCPACK_STRIP_FILES has no effect with relative CPACK_PACKAGING_INSTALL_PREFIX pathI use CPack to create a .deb package and noticed that stripping of binaries did not work in one project, but it did in another.
After a bit of testing I was able to reduce the change in behaviour to one setting:
CPACK_PACKAGING_INSTALL_P...I use CPack to create a .deb package and noticed that stripping of binaries did not work in one project, but it did in another.
After a bit of testing I was able to reduce the change in behaviour to one setting:
CPACK_PACKAGING_INSTALL_PREFIX being set to a relative path (or install(... DESTINATION relative_path), without the prefix).
Example CMakeLists.txt file:
```cmake_minimum_required(VERSION 3.16)
project(Foo VERSION 1.0.0)
add_executable(foo main.cpp)
set(CPACK_GENERATOR "DEB")
set(CPACK_STRIP_FILES TRUE)
set(CPACK_DEB_COMPONENT_INSTALL ON)
set(CPACK_PACKAGE_NAME "foo")
set(CPACK_DEBIAN_PACKAGE_MAINTAINER "foo")
set(CPACK_DEBIAN_PACKAGE_DEPENDS "None")
# relative path: this breaks the stripping step
set(CPACK_PACKAGING_INSTALL_PREFIX "opt/foo")
# absolute path: with this the stripping works fine
#set(CPACK_PACKAGING_INSTALL_PREFIX "/opt/foo")
include(CPack)
install(TARGETS foo)
```
with main.cpp containing any valid C++ program.
Now setting CPACK_PACKAGING_INSTALL_PREFIX to a relative path was an oversight and not intentional. However since the rest of the build worked -- the resulting .deb package installed all files to the correct locations -- I did not notice this and was confused, why the stripping of the binary did not work.https://gitlab.kitware.com/cmake/cmake/-/issues/25623CPack Deb: "file" command output needs escaping / filtering2024-01-23T09:09:16-05:00Julian WolffCPack Deb: "file" command output needs escaping / filteringWe install a resource file with file extension ".package".
When using CPack to create a debian package, the "file" command invoked [in CPackDeb.cmake line 171](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.28.1/Modules/Internal/CPack...We install a resource file with file extension ".package".
When using CPack to create a debian package, the "file" command invoked [in CPackDeb.cmake line 171](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.28.1/Modules/Internal/CPack/CPackDeb.cmake#L171) outputs something like this:
```
/path/to/my/file.package: Hewlett-Packard Graphics Language, starting with "PACKAGEFx\332\305V\333n\3338\020}\367W\214\363$\247]z\"
```
Note the `\"` at the end.
This seems to break CMake's list handling. The subsequent call to readelf passes a long list of files as the _FILE argument.
My local fix is to remove any string containing quotes from the "file" command output before appending it to CPACK_DEB_INSTALL_FILES:
```
string(REGEX MATCH "(^.*:[^\"]*)" INSTALL_FILE_ITEM_ "${INSTALL_FILE_}")
list(APPEND CPACK_DEB_INSTALL_FILES "${CMAKE_MATCH_1}")
```
I'm not sure if this would cause other issues.https://gitlab.kitware.com/cmake/cmake/-/issues/25310Inno Setup CPack generator doesn't support modifiable component installs2023-10-10T08:58:37-04:00Craig ScottInno Setup CPack generator doesn't support modifiable component installsThe Inno Setup CPack generator added by !8399 is missing some functionality related to components. The docs are up front about this, mentioning the lack of support for dependencies between components, for example. I'm opening this issue ...The Inno Setup CPack generator added by !8399 is missing some functionality related to components. The docs are up front about this, mentioning the lack of support for dependencies between components, for example. I'm opening this issue here after discovering that it also doesn't implement the necessary things for a component-based install to be modifiable. I've investigated what it would take, and it seems like a relatively doable change, but for now I want to record the missing pieces in case someone else has the time to assemble them into a proper merge request.
First, here's the official Inno Setup docs, which should be considered the authoritative source: https://jrsoftware.org/ishelp/
The following additional block can be added to the `Modules/Internal/CPack/ISScript.template.in` file. It copies the `Setup.exe` installer to the install location, and hooks it up to the Windows Add/Remove Programs functionality. I've essentially picked out bits from the [`setup.iss` script of Inno Setup itself](https://github.com/jrsoftware/ispack/blob/main/setup.iss) (it's a bit of a gold mine of useful techniques). There are partial fragments of this around the web, but they miss bits, so I've collected the relevant parts together here for easier reference.
```
[Setup]
AppModifyPath="{app}\Setup.exe" /modify=1
[Files]
Source: "{srcexe}"; DestDir: "{app}"; DestName: "Setup.exe"; Flags: external ignoreversion; Check: not ModifyingCheck
[Code]
var
Modifying: Boolean;
function InitializeSetup(): Boolean;
begin
Modifying := ExpandConstant('{param:modify|0}') = '1';
Result := True;
end;
function ModifyingCheck: Boolean;
begin
Result := Modifying;
end;
```
The above will give you an installer that supports the "Modify" button in the Add/Remove Programs area. But if you deselect a component that is already installed, you'll get a warning from the installer that the existing component won't be removed. The following two links show how to get the desired behavior (I haven't tried it, but it looks reasonable).
* Removing deselected components when modifying an existing installation: https://stackoverflow.com/questions/52074389/how-to-uninstall-components
* Suppress installer warning about not removing deselected components: https://stackoverflow.com/questions/37631304/inno-setup-suppress-warning-if-other-component-selected
We would probably want to add a switch for projects to state that they want to make a modifiable installer. For installers that don't need it, they don't need to copy the Setup.exe to the install location, and they don't need any of the other logic mentioned above for removing components (the uninstaller just does a blanket removal of everything).https://gitlab.kitware.com/cmake/cmake/-/issues/25248presets: packagePresets options in CMakePreset not taken in account2023-09-15T06:33:47-04:00nicolas loxolpresets: packagePresets options in CMakePreset not taken in accountI am using a CMakePresets.json in order to generate an artefact of my project.
I defined various options on the buildPresets step to custom my output artefact.
Nevertheless, some of the options set are not being taken in account (package...I am using a CMakePresets.json in order to generate an artefact of my project.
I defined various options on the buildPresets step to custom my output artefact.
Nevertheless, some of the options set are not being taken in account (packageName and packageVersion).
My artefact is created with the default value for these options instead.
I might have missed something or misunderstood the behavior of the buildPreset step of the CMakePresets.json
Here is my CMakeLists.txt
```cmake
cmake_minimum_required( VERSION 3.25 )
project( AA )
add_executable( ${PROJECT_NAME} main.cpp )
install( DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/$<CONFIG>/ DESTINATION . )
include( CPack )
```
and my CMakePresets.json
```json
{
"version": 6,
"cmakeMinimumRequired":
{
"major": 3,
"minor": 25,
"patch": 0
},
"configurePresets":
[
{
"name": "VS2022_x64",
"generator": "Visual Studio 17 2022",
"binaryDir": "${sourceDir}/build/",
"architecture":
{
"value": "x64",
"strategy": "set"
}
}
],
"buildPresets":
[
{
"name": "Release",
"configurePreset": "VS2022_x64",
"configuration": "Release"
}
],
"packagePresets":
[
{
"name": "Packaging",
"configurePreset": "VS2022_x64",
"generators": [ "ZIP" ],
"configurations": [ "Release" ],
"packageName": "MYPKG",
"packageVersion": "2.0.0",
"packageDirectory": "${sourceDir}/"
}
],
"workflowPresets":
[
{
"name": "packaging",
"steps":
[
{
"type": "configure",
"name": "VS2022_x64"
},
{
"type": "build",
"name": "Release"
},
{
"type": "package",
"name": "Packaging"
}
]
}
]
}
```https://gitlab.kitware.com/cmake/cmake/-/issues/25084CPack: Application not added to Start Menu if extension included in CPACK_PAC...2023-07-14T10:12:55-04:00Craig ScottCPack: Application not added to Start Menu if extension included in CPACK_PACKAGE_EXECUTABLE entriesThe original bug report is below. This turned out to be a misunderstanding due to docs for `CPACK_PACKAGE_EXECUTABLE` not being clear on its usage. The underlying problem is that `CPACK_PACKAGE_EXECUTABLE` expects the application name to...The original bug report is below. This turned out to be a misunderstanding due to docs for `CPACK_PACKAGE_EXECUTABLE` not being clear on its usage. The underlying problem is that `CPACK_PACKAGE_EXECUTABLE` expects the application name to be given without any path _or file extension_. Specifically, on Windows you must not add the `.exe` or `.com` extension.
The docs for `CPACK_PACKAGE_EXECUTABLE` should be improved to make this clear.
<details><summary>Original bug report</summary>
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)
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)
set(CPACK_PACKAGE_EXECUTABLES
"MainApp.exe" "Compulsory MyProj app"
)
include(CPack)
```
My understanding of the CPack Inno Setup Generator docs is that this should result in a folder in the Start Menu with the name "MyProj", and there should be an entry under that with the name "Compulsory MyProj app" that runs `MainApp.exe`. However, neither of those is created. It seems like nothing is added to the Start Menu at all.
If you add a separate item as a link menu item, that does work:
```cmake
set(CPACK_INNOSETUP_MENU_LINKS
"https://cmake.org" "CMake Web Site"
)
```
The menu link results in the folder being created in the Start Menu and the expected link under it as well. But still no entry for `MainApp.exe`.
</details>https://gitlab.kitware.com/cmake/cmake/-/issues/25046Inconsistent use of CPACK_TEMPORARY_DIRECTORY and CPACK_TEMPORARY_INSTALL_DIR...2023-06-30T17:09:06-04:00Craig ScottInconsistent use of CPACK_TEMPORARY_DIRECTORY and CPACK_TEMPORARY_INSTALL_DIRECTORYIt looks like most of the CPack code uses `CPACK_TEMPORARY_DIRECTORY` when it wants to refer to the staging area where a project is installed to. But it is actually `CPACK_TEMPORARY_INSTALL_DIRECTORY` that is used when the project is ins...It looks like most of the CPack code uses `CPACK_TEMPORARY_DIRECTORY` when it wants to refer to the staging area where a project is installed to. But it is actually `CPACK_TEMPORARY_INSTALL_DIRECTORY` that is used when the project is installed. It just so happens that by default, both variables have the same value. From what I can tell, they should always be the same, and it looks like things would break if they aren't. It appears to be a bug that we have two different variables for this, but since they default to the same value and neither is documented as writable (see below), we currently get away with it. !8566 proposes to start documenting at least one of the two, but that will then open us up to a stronger likelihood that we will encounter cases where the values may differ. Also see #21520 for context.
The `CPACK_TEMPORARY_DIRECTORY` variable is already mentioned briefly in the documentation for the `External` CPack generator. That documentation is technically inaccurate, since it is `CPACK_TEMPORARY_INSTALL_DIRECTORY` that specifies/controls where the staging install happens, not `CPACK_TEMPORARY_DIRECTORY` (CC: @kyle.edwards). There is a similar error in the code comments in `cmCPackGenerator.cxx`. The `CPACK_TEMPORARY_INSTALL_DIRECTORY` isn't currently mentioned anywhere in the docs at all.
It is clear that there will already be projects in the wild that use these two variables, despite them being undocumented. Any change that seeks to address the problem of having two separate variables for this will need to consider how to avoid breaking such projects. It seems likely that any such change would need a policy, but since this problem is in cpack rather than cmake, our ability to solve this with a policy may be restricted.https://gitlab.kitware.com/cmake/cmake/-/issues/25045CPack: NSIS.template.in defines INST_DIR but that may be a typo2023-06-30T10:06:03-04:00Craig ScottCPack: NSIS.template.in defines INST_DIR but that may be a typoThe `NSIS.template.in` file contains the following lines near the top:
```
; You must define these values
!define VERSION "@CPACK_PACKAGE_VERSION@"
!define PATCH "@CPACK_PACKAGE_VERSION_PATCH@"
!define INST_DIR "@CPACK_TEMPORARY...The `NSIS.template.in` file contains the following lines near the top:
```
; You must define these values
!define VERSION "@CPACK_PACKAGE_VERSION@"
!define PATCH "@CPACK_PACKAGE_VERSION_PATCH@"
!define INST_DIR "@CPACK_TEMPORARY_DIRECTORY@"
```
There's no explanation for why these must be defined, and in particular I cannot find any further reference to `INST_DIR`. The file uses `$INSTDIR` in many places, but I don't know if that is the same thing, or just a coincidentally similar name for something else (possibly install-time versus package creation time, but I am not sufficiently familiar with the NSIS logic to know). Either way, the purpose of the variable should be determined and the comment updated so that it is clear what `INST_DIR` is used for, other whether it is indeed a typo. The `VERSION` and `PATCH` variables seem clear enough, but I haven't looked any further at those.https://gitlab.kitware.com/cmake/cmake/-/issues/25044CPackRPM: %pretrans scriptlet violates guidelines2023-06-30T11:25:39-04:00Sergei GolubchikCPackRPM: %pretrans scriptlet violates guidelinesaccording to, say, Fedora guidelines (https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/)
> Note that the `%pretrans` scriptlet will, in the particular case of system installation, run before anything at all has been ...according to, say, Fedora guidelines (https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/)
> Note that the `%pretrans` scriptlet will, in the particular case of system installation, run before anything at all has been installed. This implies that it cannot have any dependencies at all. For this reason, `%pretrans` is best avoided, but if used it MUST (by necessity) be written in Lua
The syntax for that is `%pretrans -p <lua>`https://gitlab.kitware.com/cmake/cmake/-/issues/25017CPackRPM incorrectly sets DESTDIR for the pre-installation step (2023.06.21.)2023-07-17T07:59:59-04:00Attila KrasznahorkayCPackRPM incorrectly sets DESTDIR for the pre-installation step (2023.06.21.)This issue started out its life under: https://discourse.cmake.org/t/cpackrpm-installing-unnecessary-files But by now I'm pretty sure that there's an issue in the CMake code, so it seems better to put this into a ticket.
The back-story ...This issue started out its life under: https://discourse.cmake.org/t/cpackrpm-installing-unnecessary-files But by now I'm pretty sure that there's an issue in the CMake code, so it seems better to put this into a ticket.
The back-story of how I came across this issue is a bit complicated. But the simplest reproducer that I could come up with for the issue is the following:
```cmake
# Set up the project.
cmake_minimum_required(VERSION 3.10)
project(CPackWithExternalProject VERSION 1.0.0 LANGUAGES C)
# CMake include(s).
include(CPack)
include(ExternalProject)
# Build GoogleTest as an external package.
ExternalProject_Add(Eigen
INSTALL_DIR "${CMAKE_BINARY_DIR}/eigen"
URL "https://gitlab.com/libeigen/eigen/-/archive/3.3.7/eigen-3.3.7.tar.gz"
URL_MD5 "9e30f67e8531477de4117506fe44669b"
CMAKE_CACHE_ARGS
-DCMAKE_INSTALL_PREFIX:PATH=<INSTALL_DIR>
-DBUILD_TESTING:BOOL=FALSE
-DEIGEN_BUILD_DOC:BOOL=FALSE
-DEIGEN_TEST_NOQT:BOOL=TRUE)
```
When I build it with the "normal" configure->build->package chain of commands, I correctly get an empty RPM file.
```
Singularity> cmake ../source/
-- The C compiler identification is GNU 11.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /cvmfs/sft.cern.ch/lcg/releases/gcc/11.2.0-8a51a/x86_64-centos7/bin/gcc - skipped
...
Singularity> make
[ 12%] Creating directories for 'Eigen'
[ 25%] Performing download step (download, verify and extract) for 'Eigen'
-- Downloading...
dst='/srv/build/Eigen-prefix/src/eigen-3.3.7.tar.gz'
timeout='none'
...
[100%] Completed 'Eigen'
[100%] Built target Eigen
Singularity> cpack -G RPM
CPack: Create package using RPM
CPack: Install projects
CPack: - Run preinstall target for: CPackWithExternalProject
CPack: - Install project: CPackWithExternalProject []
CPack: Create package
CPackRPM: Will use GENERATED spec file: /srv/build/_CPack_Packages/Linux/RPM/SPECS/cpackwithexternalproject.spec
CPack: - package: /srv/build/CPackWithExternalProject-1.0.0-Linux.rpm generated.
Singularity> ls -l CPackWithExternalProject-1.0.0-Linux.rpm
-rw-rw-r-- 1 krasznaa krasznaa 1812 Jun 20 20:19 CPackWithExternalProject-1.0.0-Linux.rpm
Singularity>
```
But if I try to do a not-completelt-standard configure->package series of commands, I get the following:
```
Singularity> cmake ../source/
-- The C compiler identification is GNU 11.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /cvmfs/sft.cern.ch/lcg/releases/gcc/11.2.0-8a51a/x86_64-centos7/bin/gcc - skipped
...
-- Configuring done
-- Generating done
-- Build files have been written to: /srv/build
Singularity> cpack -G RPM
CPack: Create package using RPM
CPack: Install projects
CPack: - Run preinstall target for: CPackWithExternalProject
CPack: - Install project: CPackWithExternalProject []
CPack: Create package
CMake Warning (dev) at /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/Cmake/3.24.3/Linux-x86_64/share/cmake-3.24/Modules/Internal/CPack/CPackRPM.cmake:188 (message):
CPackRPM:Warning: Path /srv/build/eigen/include/eigen3/Eigen/Cholesky is
not on one of the relocatable paths! Package will be partially relocatable.
Call Stack (most recent call first):
/cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/Cmake/3.24.3/Linux-x86_64/share/cmake-3.24/Modules/Internal/CPack/CPackRPM.cmake:1056 (cpack_rpm_prepare_relocation_paths)
/cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/Cmake/3.24.3/Linux-x86_64/share/cmake-3.24/Modules/Internal/CPack/CPackRPM.cmake:1968 (cpack_rpm_generate_package)
This warning is for project developers. Use -Wno-dev to suppress it.
...
CMake Warning (dev) at /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/Cmake/3.24.3/Linux-x86_64/share/cmake-3.24/Modules/Internal/CPack/CPackRPM.cmake:188 (message):
CPackRPM:Warning: Path /srv/build/eigen/share/pkgconfig/eigen3.pc is not on
one of the relocatable paths! Package will be partially relocatable.
Call Stack (most recent call first):
/cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/Cmake/3.24.3/Linux-x86_64/share/cmake-3.24/Modules/Internal/CPack/CPackRPM.cmake:1056 (cpack_rpm_prepare_relocation_paths)
/cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/Cmake/3.24.3/Linux-x86_64/share/cmake-3.24/Modules/Internal/CPack/CPackRPM.cmake:1968 (cpack_rpm_generate_package)
This warning is for project developers. Use -Wno-dev to suppress it.
CPackRPM: Will use GENERATED spec file: /srv/build/_CPack_Packages/Linux/RPM/SPECS/cpackwithexternalproject.spec
CPack: - package: /srv/build/CPackWithExternalProject-1.0.0-Linux.rpm generated.
Singularity> ls -l CPackWithExternalProject-1.0.0-Linux.rpm
-rw-rw-r-- 1 krasznaa krasznaa 1014476 Jun 20 20:22 CPackWithExternalProject-1.0.0-Linux.rpm
Singularity>
```
In this case a whole lot of unwanted files end up in the RPM file. Files that were meant to end up in `${CMAKE_BINARY_DIR}/eigen`, but because `$DESTDIR` is set by CPackRPM for the preinstall step, they rather end up in the directory that the RPM is built out of.
Note that I don't see anything like this when generating TGZ packages. Even when using
```cmake
if( "${CPACK_GENERATOR}" STREQUAL "TGZ" )
# CPACK_SET_DESTDIR is necessary for the TGZ generator when using the custom
# cpack_install.sh.in script, but must not be set for the RPM generator.
set( CPACK_SET_DESTDIR TRUE )
endif()
```
inside of [CPACK_PROJECT_CONFIG_FILE](https://cmake.org/cmake/help/latest/module/CPack.html#variable:CPACK_PROJECT_CONFIG_FILE). So I have a very strong suspicion that the source of all of these issues is in:
https://gitlab.kitware.com/cmake/cmake/-/blob/v3.26.4/Source/CPack/cmCPackRPMGenerator.cxx#L26-28
:thinking:https://gitlab.kitware.com/cmake/cmake/-/issues/24939CPack/WiX: Support generating installer with per-user / per-machine option2023-11-28T08:18:54-05:00Elvis StansvikCPack/WiX: Support generating installer with per-user / per-machine optionWe use CPack to generate an installer using WiX. We've received a client request that our installer should offer the choice of per-user or per-machine installation, and that the former should not result in an administrator authentication...We use CPack to generate an installer using WiX. We've received a client request that our installer should offer the choice of per-user or per-machine installation, and that the former should not result in an administrator authentication prompt from Windows UAC.
The closest I could issue I could find was the bug report #23907+.
I guess my first question would be: Is this at all possible currently, e.g. through a custom WiX template? Are you aware of any project using CPack+WiX which has achieved this? @nilsgladitz @ben.boeckel @brad.king
So far for our application, we've tried to stay as far away as possible from WiX XML, only using a CPACK_WIX_PATCH_FILE to set up some file associations, but I'm prepared to roll up my sleeves if there's some confirmation that it is possible with a CPACK_WIX_TEMPLATE.
Or will I be bitten by bugs like #23907+https://gitlab.kitware.com/cmake/cmake/-/issues/24892CPack/NuGet: Warning NU51282023-05-11T05:13:30-04:00Mathieu MalaterreCPack/NuGet: Warning NU5128Reading the NuGet document page does not seems to provide a way to avoid the following warning:
> cmake --build build --target package --config Release
[...]
EXEC : warning : NU5128: Some target frameworks declared in the dependencies g...Reading the NuGet document page does not seems to provide a way to avoid the following warning:
> cmake --build build --target package --config Release
[...]
EXEC : warning : NU5128: Some target frameworks declared in the dependencies group of the nuspec and the lib/ref folder do not have exact matches in the other location. Consult the list of actions below: [C:\
Users\mmalaterre\projects\CMake-Nuget\build\package.vcxproj]
Per documentation upstream:
* https://learn.microsoft.com/en-us/nuget/reference/errors-and-warnings/nu5128
So all I would be missing seems to be something like this:
```
<package>
<metadata>
...
<dependencies>
<group targetFramework=".NETFramework4.7.2" />
</dependencies>
</metadata>
...
</package>
```
However cmake/NuGet only expose:
```
set(CPACK_NUGET_PACKAGE_DEPENDENCIES "targetFramework")
set(CPACK_NUGET_PACKAGE_DEPENDENCIES_targetFramework_VERSION "net5.0")
```
which gets exposed as:
```
<dependencies>
<dependency id="targetFramework" version="net5.0" />
</dependencies>
```
So please extend, CPack/NuGet to handle warning NU5128.https://gitlab.kitware.com/cmake/cmake/-/issues/24305CPack/NSIS: preinstall commands runs after components are installed2023-01-11T17:45:19-05:00Viachaslau KhalikinCPack/NSIS: preinstall commands runs after components are installedNSIS installer generated by CPack put commands from `CPACK_NSIS_EXTRA_PREINSTALL_COMMANDS` after processing of the [components](https://cmake.org/cmake/help/latest/module/CPackComponent.html) section, which is not very logical.
For exam...NSIS installer generated by CPack put commands from `CPACK_NSIS_EXTRA_PREINSTALL_COMMANDS` after processing of the [components](https://cmake.org/cmake/help/latest/module/CPackComponent.html) section, which is not very logical.
For example: when needed to _kill_ process silently before coping (updating) target files:
* in case of installer without components will executed correctly
* in case if installer support components, _kill_ will be executed only after an attempt to coping components files, which might be useless.https://gitlab.kitware.com/cmake/cmake/-/issues/24173CPackDeb dpkg-shlibdeps with sysroot while cross-compiling2024-02-01T09:54:27-05:00user706CPackDeb dpkg-shlibdeps with sysroot while cross-compilingHi, I'm cross-compiling to target armhf (raspberry-pi) using an amd64 docker host.
Details: sysroot is `/sysroot` so `CMAKE_SYSROOT` is set to `/sysroot`
`CMakeList.txt` has
```
set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS ON)
```
I have proble...Hi, I'm cross-compiling to target armhf (raspberry-pi) using an amd64 docker host.
Details: sysroot is `/sysroot` so `CMAKE_SYSROOT` is set to `/sysroot`
`CMakeList.txt` has
```
set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS ON)
```
I have problem when running cpack:
```
CMake Error at /usr/share/cmake-3.13/Modules/Internal/CPack/CPackDeb.cmake:256 (message):
CPackDeb: dpkg-shlibdeps: 'dpkg-shlibdeps: warning: cannot determine CC
system type, falling back to default (native compilation)
dpkg-shlibdeps: error: cannot find library libboost_filesystem.so.1.67.0
needed by ./usr/bin/roper-file-rename-daemon (ELF format: 'elf32-little'
abi: '0101002800000000'; RPATH: '')
dpkg-shlibdeps: error: cannot find library libdl.so.2 needed by
./usr/bin/roper-file-rename-daemon (ELF format: 'elf32-little' abi:
'0101002800000000'; RPATH: '')
dpkg-shlibdeps: error: cannot find library libpthread.so.0 needed by
./usr/bin/roper-file-rename-daemon (ELF format: 'elf32-little' abi:
'0101002800000000'; RPATH: '')
...
```
Well that's just horrid because those libs that it cannot find are in
* `/sysroot` (e.g. `/sysroot/lib/arm-linux-gnueabihf/...` ; `/sysroot/usr/lib/arm-linux-gnueabihf/...`)
and in the
* `native crosscompiler-locations` (`/usr/arm-linux-gnueabihf/lib/...` e.g. libstdc++.so.6)
Now... running command (see https://gitlab.kitware.com/cmake/cmake/-/issues/17447#note_347535) :
`LD_LIBRARY_PATH=/sysroot/usr/lib/arm-linux-gnueabihf:/sysroot/lib/arm-linux-gnueabihf:/usr/arm-linux-gnueabihf/lib:${LD_LIBRARY_PATH} cpack`
it works, but if I inspect the generated deb's controlfile like this:
```bash
mkdir tmp
cd tmp
ar x ../*.deb
tar xf control.tar.gz
cat control
```
I see the `control` file has
```
Architecture: armhf
Depends: libc6:armhf (>= 2.28), libgcc1-armhf-cross (>= 1:4.0), libstdc++6:armhf
```
That's still not entirely correct, because it's only listing "native" packages, not packages from `/sysroot`.
If I compile pseudo-natively in a chroot with qemu (or as a fool-with-endless-time-on-his-hands on the real raspberry pi), then it looks differently:
```
Architecture: armhf
Depends: libboost-filesystem1.67.0, libboost-system1.67.0, libc6 (>= 2.28), libgcc1 (>= 1:4.0), libhdf5-103, libhdf5-cpp-103 (>= 1.10.4), libsqlite3-0 (>= 3.5.9), libstdc++6 (>= 7), libsz2, zlib1g (>= 1:1.1.4)
```
Any way of fixing this?https://gitlab.kitware.com/cmake/cmake/-/issues/24092CPack WiX: Add option to skip license dialog2022-10-31T05:52:17-04:00Jordan WilliamsCPack WiX: Add option to skip license dialogThe CPack WiX generator produces an installer which contains an explicit dialog for accepting a license. This adds an additional step when it isn't required. It would be great if this could be disabled like it can be for the NSIS install...The CPack WiX generator produces an installer which contains an explicit dialog for accepting a license. This adds an additional step when it isn't required. It would be great if this could be disabled like it can be for the NSIS installer with the `CPACK_NSIS_IGNORE_LICENSE_PAGE` variable.https://gitlab.kitware.com/cmake/cmake/-/issues/24082CPack/DragNDrop: No support for UTF-8 for CPACK_RESOURCE_FILE_LICENSE2022-11-08T19:36:43-05:00Mojca MiklavecCPack/DragNDrop: No support for UTF-8 for CPACK_RESOURCE_FILE_LICENSEUnicode characters in (plain text) licence file are apparently not supported with the DragNDrop generator.
I made sure to add a BOM which lead to correctly displayed characters with NSIS, but DragNDrop installer still fails to properly e...Unicode characters in (plain text) licence file are apparently not supported with the DragNDrop generator.
I made sure to add a BOM which lead to correctly displayed characters with NSIS, but DragNDrop installer still fails to properly encode the text.
See also !7820.https://gitlab.kitware.com/cmake/cmake/-/issues/24080Allow disabling STARTMENU in NSIS CPack generator2022-11-08T19:36:57-05:00Mojca MiklavecAllow disabling STARTMENU in NSIS CPack generatorI would like to remove the "Choose Start Menu Folder" screen in the NSIS installer, but I don't find a suitable option for that.
My package only contains libraries and headers, no executable files, so it doesn't make any sense for the u...I would like to remove the "Choose Start Menu Folder" screen in the NSIS installer, but I don't find a suitable option for that.
My package only contains libraries and headers, no executable files, so it doesn't make any sense for the user to choose what and where to install to the start menu.https://gitlab.kitware.com/cmake/cmake/-/issues/24075NSIS installer created by CPack doesn't have HighDPI mode enabled2022-11-08T19:37:21-05:00Mojca MiklavecNSIS installer created by CPack doesn't have HighDPI mode enabledCMake comes with an installer that supports HighDPI out of the box, which is great.
But if I create a NSIS package via `cpack -G NSIS`, it starts in low resolution mode with ugly scaled text.
Clicking on this checkbox helps, but it wou...CMake comes with an installer that supports HighDPI out of the box, which is great.
But if I create a NSIS package via `cpack -G NSIS`, it starts in low resolution mode with ugly scaled text.
Clicking on this checkbox helps, but it would be much better if it worked out of the box.
![image](/uploads/6dea2484c827dddd481a78c43cc192ac/image.png)https://gitlab.kitware.com/cmake/cmake/-/issues/23919CPack/WiX: Allow omitting the start menu uninstaller shortcut when using star...2022-09-04T01:48:55-04:00Thomas TrummerCPack/WiX: Allow omitting the start menu uninstaller shortcut when using start menu subfoldersRelated: https://gitlab.kitware.com/cmake/cmake/-/issues/19694Related: https://gitlab.kitware.com/cmake/cmake/-/issues/19694https://gitlab.kitware.com/cmake/cmake/-/issues/23910CPack: WiX 4 support2024-03-24T15:33:30-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/23907CPack/WIX: Setting CPACK_WIX_ROOT_FOLDER_ID to local non-admin path fails2023-05-24T08:48:58-04:00Antoine HoarauCPack/WIX: Setting CPACK_WIX_ROOT_FOLDER_ID to local non-admin path failsI'm trying to package an application and install it in `%AppData%` so people don't need admin rights to install it.
Setting `set(CPACK_WIX_ROOT_FOLDER_ID "AppDataFolder")` fails with errors on all files:
```
4\WIX\files.wxs(64) : error...I'm trying to package an application and install it in `%AppData%` so people don't need admin rights to install it.
Setting `set(CPACK_WIX_ROOT_FOLDER_ID "AppDataFolder")` fails with errors on all files:
```
4\WIX\files.wxs(64) : error LGHT0204 : ICE38: Component CM_CP_my_component.boost_program_options_vc142_mt_x64_1_75.dll installs to user profile. It must use a registry key under HKCU as its KeyPath, not a file.
```
NOTE: This combination does not work as expected, it ask user to install to `C:/AppDataFolder/My Company/My App` instead of `C:/Users/myuser/AppData` etc
```cmake
set(CPACK_WIX_SKIP_PROGRAM_FOLDER true)
set(CPACK_PACKAGE_INSTALL_DIRECTORY "AppDataFolder/My Company/My App")
```
Similar issue: #20907