new port: kf6archive #46399
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,34 @@ | ||
| vcpkg_from_github( | ||
| OUT_SOURCE_PATH SOURCE_PATH | ||
| REPO KDE/karchive | ||
| REF "v${VERSION}" | ||
| SHA512 f87fd53ba029b05d3c233ea8d8a9dbb7b2aba2aec55a38b26cfd0f6e1c49d8c1297c06d634175ccc5bbbce00261a3387a2da3c705011e9cbae538eae2723fef3 | ||
| HEAD_REF master | ||
| ) | ||
|
|
||
| vcpkg_find_acquire_program(PKGCONFIG) | ||
|
|
||
| vcpkg_cmake_configure( | ||
| SOURCE_PATH "${SOURCE_PATH}" | ||
| DISABLE_PARALLEL_CONFIGURE | ||
| OPTIONS | ||
| -DBUILD_TESTING=OFF | ||
| -DPKG_CONFIG_EXECUTABLE=${PKGCONFIG} | ||
| ) | ||
|
|
||
| vcpkg_cmake_install() | ||
| vcpkg_cmake_config_fixup(CONFIG_PATH lib/cmake/KF6Archive) | ||
| vcpkg_copy_pdbs() | ||
|
|
||
| # Static builds should not have libraries in the bin directory | ||
| if(VCPKG_LIBRARY_LINKAGE STREQUAL "static") | ||
| file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/bin" "${CURRENT_PACKAGES_DIR}/debug/bin") | ||
| endif() | ||
|
|
||
| file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/bin/data") | ||
| file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/debug/bin/data") | ||
| file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/debug/include") | ||
| file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/debug/share") | ||
|
|
||
| file(GLOB LICENSE_FILES "${SOURCE_PATH}/LICENSES/*") | ||
| vcpkg_install_copyright(FILE_LIST ${LICENSE_FILES}) | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,60 @@ | ||
| { | ||
| "name": "kf6archive", | ||
|
Member
There was a problem hiding this comment. I have a couple of questions regarding the KDE Framework libraries. Is version 5 still being maintained? Does it offer a LTS version? This seems to be in a similar situation to Qt, but do we really need to keep both versions around? If the answer to any of the previous questions is "no", then we should update the existing port and maybe rename it.
Contributor
Author
There was a problem hiding this comment. For transparency, I am not a Qt nor a KDE Frameworks developer. I support an open source game that leverages Qt and the KfArchive library. Hence the port here for the Qt6 one. As I understand it based on a read here the Qt5 frameworks are in maintenance mode. I believe that is the same with Qt 5.15, which is the last of the Qt v5 LTS series. Frameworks don't do LTS, only Qt does. While Qt6 has been out now for awhile and has an LTS in v6.8, the development libraries are kind of new in the Linux world, especially Frameworks libraries. My suggestion is to keep both v5 and v6 for both Qt and the KDE Frameworks. It's going to take some time for everyone using Qt5 to get over to Qt6 I'll wager. KDE Frameworks v6 library packages aren't even in Ubuntu LTS yet. That won't happen until 26.04 I think. They were not included in 24.04. Also, I think this port of kf6archive is the only KDE Frameworks port on any library on Qt6. There is an open issue for the rest of them, but I only need the one so took it under myself to add it here. Hope this helps. There was a problem hiding this comment. Hi! The situation is indeed a bit complicated. Qt 5 is officially end-of-life, but still gets (commercial) extended support by the Qt Company. (Some of?) the changes are committed to the repos on GitHub. Kde maintains an unversioned fork based on this + other fixes they backport from Qt 6. This is used by Linux distributions that ship Qt 5 (e.g. Arch). Vcpkg uses the last release by the Qt Company (link). The latest Kde Frameworks 5 release was 5.116.0 on Sat May 19, 2024. This is used in Kde Plasma 5.27 LTS, which is still supported and had a release in January. Given the ties between Frameworks and Plasma, The Kde Qt fork and Kde Frameworks will be supported at least as long as Plasma is. There has been no end-of-life announcement so far.
Member
There was a problem hiding this comment.
According to https://endoflife.date/qt , OSS support for qt5 ended 4 years, 7 months ago, and commercial support ended 2 months ago. I think that supports flipping vcpkg's canonical version of qt to qt6 for all downstream ports that must pick one. We already did this in e.g. qtapplicationmanager.
Member
There was a problem hiding this comment.
Do the KDE frameworks take steps to not step on each others' symbols for different versions such that they can be simultaneously installed? Most libraries do not do that, qt is special for doing so. Most of the time we can usually only pick one. There was a problem hiding this comment. Frameworks 5 and 6 can be installed next to each other but not linked together in the same executable. For instance, Arch Linux has both karchive and karchive-qt5. On my Ubuntu-based distro, I have:
Member
There was a problem hiding this comment. Unfortunately vcpkg's registry models a single link domain so if they can't be linked together I think we have to pick one to be the canonical one for the curated registry.
Contributor
Author
There was a problem hiding this comment. @BillyONeal Are you suggesting we name this port There was a problem hiding this comment. (the framework name is
Member
There was a problem hiding this comment. No, I wasn't suggesting a name change, I was trying to say "can we take this at all while kf5archive exists". My understanding was that qt provided the link domain separation thing making it OK but after doing some digging with @vicroms and @ras0219-msft today it appears qt might not actually provide that unless you go out of your way to set the "namespace" for it to be in, and it doesn't appear we do that. Which means this seems to be providing the same guarantees that our qt ports are already providing, which seems like it has to be OK then even if it breaks msbuild customers that try to install both. Digging on repology looking for other kfXxx things e.g. https://repology.org/project/kio/versions our existing kf5Xxx are getting marked as part of that "project". The most common naming pattern is either no numbering at all, or kfX-name . Unfortunately that makes us a 'special snowflake' with kf5Xxx because we have no dash, but that's unfortunately too late to be worth changing now. Given that we're considering having both, I think the name already proposed here, kf6archive, is correct. |
||
| "version": "6.7.0", | ||
| "description": "File compression", | ||
| "homepage": "https://api.kde.org/frameworks/karchive/html/index.html", | ||
| "license": "LGPL-2.0-or-later", | ||
| "supports": "!xbox", | ||
| "dependencies": [ | ||
| "bzip2", | ||
| "ecm", | ||
| "liblzma", | ||
| "openssl", | ||
| "qtbase", | ||
| { | ||
| "name": "qttools", | ||
| "features": [ | ||
| "linguist" | ||
| ] | ||
| }, | ||
| { | ||
| "name": "vcpkg-cmake", | ||
| "host": true | ||
| }, | ||
| { | ||
| "name": "vcpkg-cmake-config", | ||
| "host": true | ||
| }, | ||
| "zlib", | ||
| "zstd" | ||
| ], | ||
| "default-features": [ | ||
| "bzip2" | ||
| ], | ||
| "features": { | ||
| "bzip2": { | ||
| "description": "Support for bzip2 compressed files and data streams", | ||
| "dependencies": [ | ||
| "bzip2" | ||
| ] | ||
| }, | ||
| "lzma": { | ||
| "description": "Support for xz compressed files and data streams", | ||
| "dependencies": [ | ||
| "liblzma" | ||
| ] | ||
| }, | ||
| "openssl": { | ||
| "description": "Support for compressed encrypted files and data streams", | ||
| "dependencies": [ | ||
| "openssl" | ||
| ] | ||
| }, | ||
| "zstd": { | ||
| "description": "Support for zstd compressed files and data streams", | ||
| "dependencies": [ | ||
| "zstd" | ||
| ] | ||
| } | ||
| } | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,9 @@ | ||
| { | ||
| "versions": [ | ||
| { | ||
| "git-tree": "590a13d6a936df53932719c4d98a4f4fe8c3be60", | ||
| "version": "6.7.0", | ||
| "port-version": 0 | ||
| } | ||
| ] | ||
| } |
Uh oh!
There was an error while loading. Please reload this page.