Skip to content

Add snippet for KDEInstallDirs#345

Closed
Begasus wants to merge 1 commit intohaikuports:masterfrom
Begasus:KDEInstallDirs
Closed

Add snippet for KDEInstallDirs#345
Begasus wants to merge 1 commit intohaikuports:masterfrom
Begasus:KDEInstallDirs

Conversation

@Begasus
Copy link
Copy Markdown
Member

@Begasus Begasus commented Oct 8, 2025

No description provided.

@Begasus
Copy link
Copy Markdown
Member Author

Begasus commented Oct 8, 2025

Background, upstream changes:

https://invent.kde.org/frameworks/extra-cmake-modules/-/commit/8cf1cf2851222540fcd4a6be11185a45379372a7
https://invent.kde.org/frameworks/extra-cmake-modules/-/commit/a26633dedc736e826b8815b9dfcfcf6d80b9a0ef
https://invent.kde.org/frameworks/extra-cmake-modules/-/commit/e698433a55a03eeeac33f275caa30098d810ecb1

Without it I get tons of messages like:

CMake Warning at /packages/extra_cmake_modules-6.19.0~rc1-1/.self/data/cmake/Modules/ECM/kde-modules/KDEInstallDirsCommon.cmake:169 (message):
  KDE_INSTALL_BINDIR got its value from CMAKE_INSTALL_BINDIR.  In most cases
  this is unintended, check if you included GNUInstallDirs before
  KDEInstallDirs.  Some third party modules include GNUInstallDirs too so eg.
  find_package(Qt6 ...) is equivalent to include(GNUInstallDirs).  If you set
  CMAKE_INSTALL_BINDIR deliberately before including KDEInstallDirs its
  recommended to use KDE_INSTALL_BINDIR instead to suppress this message.
Call Stack (most recent call first):
  /packages/extra_cmake_modules-6.19.0~rc1-1/.self/data/cmake/Modules/ECM/kde-modules/KDEInstallDirsCommon.cmake:255 (_define_relative)
  /packages/extra_cmake_modules-6.19.0~rc1-1/.self/data/cmake/Modules/ECM/kde-modules/KDEInstallDirs6.cmake:199 (include)
  /packages/extra_cmake_modules-6.19.0~rc1-1/.self/data/cmake/Modules/ECM/kde-modules/KDEInstallDirs.cmake:15 (include)
  CMakeLists.txt:14 (include)

@Begasus
Copy link
Copy Markdown
Member Author

Begasus commented Oct 8, 2025

Changes (kcoreaddons6): ECM_DIR fixed in extra-cmake-modules

From:

	cmake -B build -S . -DCMAKE_BUILD_TYPE=Release \
		$cmakeDirArgs \
		-DKDE_INSTALL_PLUGINDIR=$addOnsDir/Qt6 \
		-DKDE_INSTALL_QMLDIR=$dataDir/Qt6/qml \
		-DKDE_INSTALL_QTPLUGINDIR=$addOnsDir/Qt6 \
		-DECM_DIR=/system/data/cmake/Modules/ECM/cmake \
		-DCMAKE_SKIP_RPATH=YES \
		-DBUILD_TESTING=OFF \
		-Wno-dev

To:

	cmake -B build -S . -DCMAKE_BUILD_TYPE=Release \
		-DCMAKE_INSTALL_PREFIX=$prefix \
		$KDEDirArgs \
		-DKDE_INSTALL_PLUGINDIR=$addOnsDir/Qt6 \
		-DKDE_INSTALL_QMLDIR=$dataDir/Qt6/qml \
		-DKDE_INSTALL_QTPLUGINDIR=$addOnsDir/Qt6 \
		-DCMAKE_SKIP_RPATH=YES \
		-DBUILD_TESTING=OFF \
		-Wno-dev

@Begasus Begasus marked this pull request as draft October 8, 2025 09:40
@Begasus Begasus marked this pull request as ready for review October 11, 2025 10:00
@Begasus
Copy link
Copy Markdown
Member Author

Begasus commented Oct 16, 2025

Any thoughts on this? This doesn't brake anything and is only used for KDE projects. Would be nice if this was included before the next major update for those (probably in December).
@korli @waddlesplash @kallisti5 @pulkomandy @diversys @threedeyes (and anyone else keeping track here). :)

@korli
Copy link
Copy Markdown
Contributor

korli commented Oct 16, 2025

Would KDEDirArgs cumulate cmakeDirArgs?

@Begasus
Copy link
Copy Markdown
Member Author

Begasus commented Oct 16, 2025

cumulate

Not sure what you mean by "cumulate", it will replace the arguments used by cmake like

KDE_INSTALL_BINDIR vs CMAKE_INSTALL_BINDIR

Only rule that doesn't apply is KDE_INSTALL_PREFIX for that we still have to use CMAKE_INSTALL_PREFIX (reported upstream).

In other words one would use KDEDirArgs instead of cmakeDirArgs in recipes if that is what you mean?

@korli
Copy link
Copy Markdown
Contributor

korli commented Oct 16, 2025

I mean, shouldn't KDEDirArgs define all arguments from cmakeDirArgs plus the two for kde? Why would that hurt?

@Begasus
Copy link
Copy Markdown
Member Author

Begasus commented Oct 16, 2025

Hoping to get the right answer here :) KDEDirArgs "redefines" the cmakeDirArgs arguments with this. It doesn't hurt anything yet, but could be in the future? (things still build with cmakeDirArgs).
On another note, upstream will switch to Qt >= 6.8 shortly making this kinda obsolete until we can bump version there. :(

@korli
Copy link
Copy Markdown
Contributor

korli commented Oct 16, 2025

I now looked at the upstream changes you linked. Looks like a mess to me. A snippet is supposed to be a stable thing, otherwise it won't help you much. IMO it would be better if some snippets were direct in the haikuports repo.

@jmairboeck
Copy link
Copy Markdown
Member

If we add snippets to haikuports which can be sourced by multiple recipes, we would probably need some mechanism to make them available in the chroot.

If we keep the layout similar to Gentoo here too, this would correspond to their eclass directory. (although I would suggest a different name for haikuports ...)

@Begasus
Copy link
Copy Markdown
Member Author

Begasus commented Oct 16, 2025

Food for thoughts, I'll set draft to this again, meanwhile I patched ECM to take advantage of QTPLUGINDIR and QMLDIR, so we wouldn't have to force those into the recipe again.

@Begasus Begasus marked this pull request as draft October 16, 2025 13:39
@Begasus
Copy link
Copy Markdown
Member Author

Begasus commented Oct 18, 2025

Closing for now, no urgent issue atm.

@Begasus Begasus closed this Oct 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants