| Summary: | dev-qt/qtdiag-5.15.0: Project ERROR: Could not find feature dom | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | William Throwe <wtt6> |
| Component: | Current packages | Assignee: | Qt Bug Alias <qt> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | abbotta4, mgorny |
| Priority: | Normal | Keywords: | PullRequest |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=795237 https://bugs.gentoo.org/show_bug.cgi?id=802492 https://bugs.gentoo.org/show_bug.cgi?id=811147 https://github.com/gentoo/qt/pull/246 https://github.com/gentoo/gentoo/pull/22138 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | build.log | ||
|
Description
William Throwe
2020-06-14 19:56:59 UTC
emerging qtxml fixed this for me that's correct, qtxml is missing in dependencies ...which is bad, because it means the "-no-feature-$PN" switches do not properly disable these modules. Should we just add that DEPEND even though we know it is bogus, and be done with it? (In reply to Andreas Sturmlechner from comment #4) > Should we just add that DEPEND even though we know it is bogus, and be done > with it? Sounds acceptable to me, although I'm not following your previous comment about -no-feature-$PN not producing the expected effect. (In reply to Davide Pesavento from comment #5) > Sounds acceptable to me, although I'm not following your previous comment > about -no-feature-$PN not producing the expected effect. Well, dependency checks being executed for disabled modules causing this bug. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=440b12fb459a0efc35c2192e5bc1ec66c4f810f2 commit 440b12fb459a0efc35c2192e5bc1ec66c4f810f2 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2020-09-29 20:23:52 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2020-09-29 20:29:41 +0000 dev-qt/qtdiag: Add dev-qt/qtxml to DEPEND Bug: https://bugs.gentoo.org/728278 Package-Manager: Portage-3.0.8, Repoman-3.0.1 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> dev-qt/qtdiag/qtdiag-5.15.1.ebuild | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/qt.git/commit/?id=6098eb4751ce773126722792a5fa955ac1d7c83f commit 6098eb4751ce773126722792a5fa955ac1d7c83f Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2020-09-29 20:23:52 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2020-09-29 20:33:15 +0000 dev-qt/qtdiag: Add dev-qt/qtxml to DEPEND Bug: https://bugs.gentoo.org/728278 Package-Manager: Portage-3.0.8, Repoman-3.0.1 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> dev-qt/qtdiag/qtdiag-5.15.9999.ebuild | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (In reply to Andreas Sturmlechner from comment #6) > (In reply to Davide Pesavento from comment #5) > > Sounds acceptable to me, although I'm not following your previous comment > > about -no-feature-$PN not producing the expected effect. > Well, dependency checks being executed for disabled modules causing this bug. Some investigation revealed that the "skip this module" check in each subdir of qttools, e.g.: requires(qtConfig(qdbus)) does NOT cause the evaluation of the current .pro file to stop and return early. All following checks are still executed. This is annoying because some later checks such as qtConfig(dom) complain loudly and error out if the feature being tested ("dom" in this example) is neither in enabled_features nor in disabled_features of any of the installed Qt5 modules. One workaround is to add "|return()" after each "requires(...)" invocation in src/${foo}/${foo}.pro Though, I need to ask, why can't we just run qmake&&make in the QT5_TARGET_SUBDIRS like we used to? QT5_TARGET_SUBDIRS was dropped [1] from some but not all qttools ebuilds, but I'm not sure why. This would be in addition to running qmake from the root dir, which seems to be required now [2] and there's not much we can do about it. [1] https://github.com/gentoo/qt/pull/218 [2] https://bugs.gentoo.org/716514 (In reply to Davide Pesavento from comment #10) > One workaround is to add "|return()" after each "requires(...)" invocation > in src/${foo}/${foo}.pro We shall look into that, thanks. (In reply to Davide Pesavento from comment #10) > Though, I need to ask, why can't we just run qmake&&make in the > QT5_TARGET_SUBDIRS like we used to? QT5_TARGET_SUBDIRS was dropped [1] from > some but not all qttools ebuilds, but I'm not sure why. This would be in > addition to running qmake from the root dir, which seems to be required now > [2] and there's not much we can do about it. > > [1] https://github.com/gentoo/qt/pull/218 > [2] https://bugs.gentoo.org/716514 The current solution enabled us to drop (see commit d6765662) the following hackery after several back and forths [1] from bugs about different behaviour between release and live build mode: > src_configure() { > # Most of qttools require files that are only generated when qmake is > # run in the root directory. > # Related bugs: 633776, 676948, and 716514. > mkdir -p "${QT5_BUILD_DIR}" || die > qt5_qmake "${QT5_BUILD_DIR}" > cp "${S}"/qttools-config.pri "${QT5_BUILD_DIR}" || die > qt5-build_src_configure > } Those were required for dev-qt/designer, dev-qt/pixeltool, dev-qt/qdoc (the fix did look slightly different there), dev-qt/qtdiag, dev-qt/qtpaths, dev-qt/qtplugininfo. I guess using the same method for the remaining qttools derived packages would be possible, but was not looked into because they seem to work without the previous hack. Interesting though that dev-qt/linguist-tools was not converted and still uses the old method. [1] https://bugs.gentoo.org/676948 (In reply to Andreas Sturmlechner from comment #11) > The current solution enabled us to drop (see commit d6765662) the following > hackery [...] Yeah I understand the part where we run qmake in the (shadow) root dir to create qttools-config.pri, it's a good solution and we should keep it. The part I don't understand is why this logic (qt5_tools_configure function) is run only when QT5_TARGET_SUBDIRS is empty. IOW, we can keep the existing qt5_tools_configure logic AND still set QT5_TARGET_SUBDIRS appropriately so that make is run only inside those subdirs, thus avoiding irrelevant dependency checks. I tested this with qtdiag-5.15.2 and it seems to work, but I haven't tried any live ebuilds yet (and I'll be offline for the next several days). > Interesting though that > dev-qt/linguist-tools was not converted and still uses the old method. linguist-tools has QT5_TARGET_SUBDIRS=(src/linguist). That prevents the qt5_tools_configure logic from running which means qttools-config.pri is not created. However, the .pro file in src/linguist does require that file to exist, so the aforementioned hackery had to be kept in the ebuild. Again, as I said above, I don't know why qt5_tools_configure and QT5_TARGET_SUBDIRS are mutually exclusive. (In reply to Davide Pesavento from comment #12) > (In reply to Andreas Sturmlechner from comment #11) > > The current solution enabled us to drop (see commit d6765662) the following > > hackery [...] > Yeah I understand the part where we run qmake in the (shadow) root dir to > create qttools-config.pri, it's a good solution and we should keep it. > > The part I don't understand is why this logic (qt5_tools_configure function) > is run only when QT5_TARGET_SUBDIRS is empty. I think that was simply done to keep both methods entirely separate so as to not break existing stable ebuilds using QT5_TARGET_SUBDIRS. (In reply to Davide Pesavento from comment #12) > IOW, we can keep the existing qt5_tools_configure logic AND still set > QT5_TARGET_SUBDIRS appropriately so that make is run only inside those > subdirs, thus avoiding irrelevant dependency checks. I tested this with > qtdiag-5.15.2 and it seems to work, but I haven't tried any live ebuilds yet > (and I'll be offline for the next several days). Since all stable qttools submodules in tree are currently still EAPI-7, I'm thinking of replacing that with an EAPI==8 check and try out your suggestion. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/qt.git/commit/?id=18416c5d4797ba363d217e574e967c15aaf39eaa commit 18416c5d4797ba363d217e574e967c15aaf39eaa Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2021-09-05 11:17:11 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2021-09-05 18:23:24 +0000 qt5-build.eclass: Always run qt5_tools_configure for QT5_MODULE=qttools Run qt5_qmake directly inside qt5_tools_configure(), copy the resulting qttools-config.pri into QT5_BUILD_DIR again. Add linguist-tools handling. Bug: https://bugs.gentoo.org/728278 Bug: https://bugs.gentoo.org/811147 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> eclass/qt5-build.eclass | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2aad1931f8a03c77c16f6664d51afdc190efe8aa commit 2aad1931f8a03c77c16f6664d51afdc190efe8aa Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2021-09-05 11:17:11 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2021-09-08 16:54:32 +0000 qt5-build.eclass: Always run qt5_tools_configure for QT5_MODULE=qttools Run qt5_qmake directly inside qt5_tools_configure(), copy the resulting qttools-config.pri into QT5_BUILD_DIR again. Add linguist-tools handling. Closes: https://bugs.gentoo.org/728278 Closes: https://bugs.gentoo.org/811147 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> eclass/qt5-build.eclass | 25 ++++++++++++++++++++----- 1 file changed, 20 insertions(+), 5 deletions(-) |
