Bug 257615

Summary:	devel/cmake: CPack FreeBSD generator fails after upgrade to pkg-1.17.0
Product:	Ports & Packages	Reporter:	Peter Laursen <freebsd>
Component:	Individual Port(s)	Assignee:	freebsd-kde (group) <kde>
Status:	Closed FIXED
Severity:	Affects Only Me	CC:	adridg
Priority:	---	Flags:	bugzilla: maintainer-feedback? (kde)
Version:	Latest
Hardware:	Any
OS:	Any

Description Peter Laursen 2021-08-04 11:43:14 UTC

Hi,
The CPack FreeBSD package generator fails to copy the final generated package if pkg-1.17 or any later version is installed.
The problem turns out to be simple to fix. After the package prefix was changed from ".txz" to ".pkg", the CPack Generator can no longer find its package, leading to it failing. However, the package is generated as expected, just not copied to its final location.

A possibly temporary fix is to change the package suffix in the file "files/patch-cmake-issue-18031", line 19,  from ".txz" to ".pkg".
At least, this fixes the bug in my local testing and the package is generated (and copied) as expected.

All the best,

Peter.

Comment 1 Adriaan de Groot freebsd_committer

2021-09-20 17:16:48 UTC

I keep intending to upstream this and never quite getting around to it, but here we have libpkg changing in a surprising way underneath us -- `pkg_create()` doesn't offer a way to find out what filename was actually used (and no versioning API either).

Comment 2 commit-hook freebsd_committer

2021-09-21 09:28:15 UTC

A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=aeb5f9cf181c597d6c2c5fcb0497b2bce116896f

commit aeb5f9cf181c597d6c2c5fcb0497b2bce116896f
Author:     Adriaan de Groot <adridg@FreeBSD.org>
AuthorDate: 2021-09-21 09:16:05 +0000
Commit:     Adriaan de Groot <adridg@FreeBSD.org>
CommitDate: 2021-09-21 09:27:23 +0000

    devel/cmake: fix CPack .pkg support, jump to 3.21.3

    Update the patch for FreeBSD .pkg support in CPack to handle
    libpkg 1.17 and later's use of .pkg as package-suffix rather
    than .tgz. The PR below refers to this fix. I've kept code
    for older libpkg in case there are systems with weirdly
    mismatched current CMake and last-quarter's libpkg.

    The patch is still being upstreamed. The PR mentioned below
    is for this fix.

    While here, update to 3.21.3.  I've decided to -- unusual,
    for sure -- bump CMake without the usual exp-run, because:

    A regression in CMake 3.21.2 prompted a quick release of
    3.21.3 from upstream. The regression applies to the AMD ROCm
    platform, so that's not us. Other fixes in 3.21.3 apply to supported
    MSVC versions -- again, not us.

    There is new support for Boost 1.77 -- not in our ports yet.

    In other words, the git diff on CMake sources does not show
    anything that could affect us (famous last words). Release notes are at
            https://cmake.org/cmake/help/v3.21/release/3.21.html#id3

    PR:             257615
    Reported by:    Peter Laursen

 devel/cmake-doc/Makefile                  |  2 +-
 devel/cmake-gui/Makefile                  |  2 +-
 devel/cmake/Makefile                      |  2 +-
 devel/cmake/distinfo                      |  6 +--
 devel/cmake/files/patch-cmake-issue-18031 | 64 +++++++++++++++++++++++--------
 devel/cmake/pkg-plist                     | 10 -----
 6 files changed, 53 insertions(+), 33 deletions(-)

Comment 3 Adriaan de Groot freebsd_committer

2021-09-21 09:29:56 UTC

Totally minimal CMakeLists.txt (creates a source file if needed!) to test this:

```
cmake_minimum_required(VERSION 3.21 FATAL_ERROR)
project(cpack-example VERSION 0.1 LANGUAGES C)

set(CPACK_PACKAGE_CONTACT "groot@kde.org")
set(CPACK_RPM_PACKAGE_LICENSE "GPLv2")

include(CPack)

if(NOT EXISTS ${CMAKE_SOURCE_DIR}/hw.c)
    file(WRITE ${CMAKE_SOURCE_DIR}/hw.c "int main() { return 0; }")
endif()

add_executable(hw hw.c)
install(TARGETS hw DESTINATION bin)
```

And it now creates a .pkg which installs and deinstalls successfully.