Variable Qt5Widgets_PRIVATE_INCLUDE_DIRS appears empty in qt5/style/CMakeLists.txt. It seems, for maintainer int works. Issue on github, still no known solution: https://github.com/QtCurve/qtcurve/issues/35 Marking as major, since indeed - Major Feature is broken :) Reproducible: Always Steps to Reproduce: Just try to build with qt5 support
More exactly it happens on argbhelper.cpp in qt5 sruff.
Might be an issue with qtwidgets ebuild, needs investigation.
*** Bug 499882 has been marked as a duplicate of this bug. ***
It seems like all Qt5_*_PRIVATE_INCLUDE_DIRS are empty in Qt5*Config.cmake files. For instance on ArchLinux: $ grep -A 3 -m 1 Qt5Core_PRIVATE_INCLUDE_DIRS /usr/lib64/cmake/Qt5Core/Qt5CoreConfig.cmake set(Qt5Core_PRIVATE_INCLUDE_DIRS "${_qt5Core_install_prefix}/include/qt/QtCore/5.2.1" "${_qt5Core_install_prefix}/include/qt/QtCore/5.2.1/QtCore" ) On Gentoo: set(Qt5Core_PRIVATE_INCLUDE_DIRS "") include("${CMAKE_CURRENT_LIST_DIR}/ExtraSourceIncludes.cmake" OPTIONAL) foreach(_dir ${_Qt5Core_OWN_INCLUDE_DIRS}) And it is true for other *Config.cmake files
Arch does an in-source build, right?
Removing "CMAKE_NO_PRIVATE_INCLUDES = true" from create_cmake.prf fixes it, although I'm not sure if that's the proper fix. I also found some inconsistencies (bugs possibly) elsewhere in that same file wrt the handling of ExtraSourceIncludes.cmake, thus I'd like to speak with upstream about the whole thing first.
> Arch does an in-source build, right? Yes
Which Qt version are you using? I had a problem like this with QtGui and KF5, but only with 5.2.1 - it works fine with 5.9999
Created attachment 370550 [details, diff] patch to fix a problem generate ExtraSourceIncludes.cmake which will be included by the Qt5xxxConfig.cmake and define xxx_PRIVATE_INCLUDE_DIRS in it... so packages like kf5 KGuiAddons can compile
(In reply to Alex Turbov from comment #9) > Created attachment 370550 [details, diff] [details, diff] > patch to fix a problem > NAK If we are going to implement a workaround, then removing CMAKE_NO_PRIVATE_INCLUDES (comment #6) is far easier.
*** Bug 501872 has been marked as a duplicate of this bug. ***
I just tried removing "CMAKE_NO_PRIVATE_INCLUDES = true", that did not fix the problem for me. Maybe bug #501872 is a different problem?
(In reply to Malte E. from comment #12) > I just tried removing "CMAKE_NO_PRIVATE_INCLUDES = true", that did not fix > the problem for me. Maybe bug #501872 is a different problem? And did you rebuild the qt module afterwards (seems to be qtgui in your case)?
I just did that, but the problem remains.
In 4fd568fa0633b17b4a8e24736a4766e81afff4f3 split_incpath is set for non-git builds (which would be why this is not an issue for qt-9999). In this case, ExtraSourceIncludes.cmake is created with set(Qt5Gui_PRIVATE_INCLUDE_DIRS /var/tmp/portage/dev-qt/...) but is not installed, which I guess is what comment #9 is trying to address. Maybe this is an artifact from assuming that (binary) distros will be packaging the private headers separately?
In any case, this is definitely related to shadow builds. It works fine in-source with our configure arguments, but not with out-of-source.
(In reply to Michael Palimaka (kensington) from comment #16) > In any case, this is definitely related to shadow builds. It works fine > in-source with our configure arguments, but not with out-of-source. Yep, I suspected that while reading the .prf files of qt build system (comment #5) and Eugene confirmed it as well.
(In reply to Michael Palimaka (kensington) from comment #15) > In 4fd568fa0633b17b4a8e24736a4766e81afff4f3 split_incpath is set for non-git > builds (which would be why this is not an issue for qt-9999). > In this case, ExtraSourceIncludes.cmake is created with > set(Qt5Gui_PRIVATE_INCLUDE_DIRS /var/tmp/portage/dev-qt/...) but is not > installed, which I guess is what comment #9 is trying to address. > I noticed that too (sorry for not reporting here, I could have saved you some time). And even if ExtraSourceIncludes.cmake were installed, the path in it is wrong because it refers to the build directory. I'm starting to think that it's not actually our fault, but rather that the build system is buggy in our particular scenario (wouldn't be the first time).
(In reply to Davide Pesavento from comment #18) > I'm starting to think that it's not actually our fault, but rather that the > build system is buggy in our particular scenario (wouldn't be the first > time). What can we do then - is there any chance of upstream actually fixing this, or should we just switch to in-source builds (at least temporarily)?
(In reply to Michael Palimaka (kensington) from comment #19) > What can we do then - is there any chance of upstream actually fixing this, I think so, maybe even for 5.3 (otherwise we can backport the fix). I suspect they don't even know about this issue however, so a good first step would be to report it :)
I filed a bug.
(In reply to Michael Palimaka (kensington) from comment #21) > I filed a bug. err... link? :)
https://bugreports.qt-project.org/browse/QTBUG-37297
Fixed the issue for me (I couldn't build kde-frameworks/kguiaddons-9999) by this change to the qt5-build.eclass: > diff --git a/eclass/qt5-build.eclass b/eclass/qt5-build.eclass > index 264e158..d331bfb 100644 > --- a/eclass/qt5-build.eclass > +++ b/eclass/qt5-build.eclass > @@ -102,7 +102,7 @@ EXPORT_FUNCTIONS pkg_setup src_unpack src_prepare src_configure src_compile src_ > # @ECLASS-VARIABLE: QT5_BUILD_DIR > # @DESCRIPTION: > # Build directory for out-of-source builds. > -: ${QT5_BUILD_DIR:=${S}_build} > +: ${QT5_BUILD_DIR:=${S}} > > # @ECLASS-VARIABLE: QT5_VERBOSE_BUILD > # @DESCRIPTION: Next, I rebuilt dev-qt/qtgui-5.2.1 and now I was able to successfully build kde-frameworks/kguiaddons-9999. So until this is fixed upstream the dev-qt/qt*-5.2* ebuild should probably set QT5_BUILD_DIR=${S} which should then be pushed to the overlay/tree as a new revision to ensure all affected packages are rebuilt.
*** Bug 504450 has been marked as a duplicate of this bug. ***
Had the same error with Qt 5.3.0 alpha, however fin in Comment 24 solves the problem.
Is this reproducible with 5.3.0_rc? (I guess so)
(In reply to Davide Pesavento from comment #27) > Is this reproducible with 5.3.0_rc? (I guess so) It looks like the changes will be in 5.3.1
(In reply to Michael Palimaka (kensington) from comment #28) > (In reply to Davide Pesavento from comment #27) > > Is this reproducible with 5.3.0_rc? (I guess so) > > It looks like the changes will be in 5.3.1 What changes are you talking about? I don't know of any patches fixing this, but if there are, we can backport them to 5.3.0
Sorry I was on the wrong bug.
*** Bug 510100 has been marked as a duplicate of this bug. ***
Can confirm that this is fixed in 5.3.1 / 5.3.9999 % grep -A 3 'set(Qt5Gui_PRIVATE_INCLUDE_DIRS' /usr/lib64/cmake/Qt5Gui/Qt5GuiConfig.cmake set(Qt5Gui_PRIVATE_INCLUDE_DIRS "${_qt5Gui_install_prefix}/include/qt5/QtGui/5.3.1" "${_qt5Gui_install_prefix}/include/qt5/QtGui/5.3.1/QtGui" )
(In reply to Uwe L. Korn from comment #32) > Can confirm that this is fixed in 5.3.1 / 5.3.9999 > Cool! Any chances you can identify the patch(es) that fixed it so that we can backport to 5.3.0?
We should be able to get *PRIVATE_INCLUDE_DIRS populated in a release build by removing lines 17-19 in mkspecs/features/qt_module_pris.prf.
I don't understand... you said this is fixed in 5.3.9999, but I don't see any changes around those lines of qt_module_pris.prf in the stable branch...
5.3.9999 has the *PRIVATE_INCLUDE_DIRS because it is a build from git, this changes behaviour which first got me thinking that there was a fix in 5.3.9999 which is obviously wrong. The mentioned lines are related to the code that deactivates the generation of the *PRIVATE_INCLUDE_DIRS contents. But just disabling these lines will break the build itself as then include paths during the build itself are wrong.
*** Bug 510746 has been marked as a duplicate of this bug. ***
I added a workaround to the eclass https://git.overlays.gentoo.org/gitweb/?p=proj/qt.git;a=commitdiff;h=8d7f7f9428e4ccddf0defc051c7067d509fefcdb
Qt 5.3 is out - may that have changed anything?
(In reply to Malte E. from comment #39) > Qt 5.3 is out - may that have changed anything? No.
FWIW, Fedora ran into the same problem and had to revert back to in-source builds. http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtbase.git/commit/?id=4a85b930ef978834794f4e11364865fe98bf441c
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/qt.git/commit/?id=548df2493d9801b2503f412ec8c424418cb7721b commit 548df2493d9801b2503f412ec8c424418cb7721b Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2020-03-31 12:21:16 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2020-04-09 18:32:31 +0000 qt5-build.eclass: Drop obsolete in-source build workaround for >=5.14.2 Fixed upstream in 5.11.1. See also: https://bugreports.qt.io/browse/QTBUG-37417 Upstream commit 67aa365d41ebfe082b4efcfd725e4d5f08be678c qtbase forwarding header was introduced to fix bug 599636 in commit: d82f92ed064996dfb187ef668d74ed5b05546b2d Bug: https://bugs.gentoo.org/497312 Bug: https://bugs.gentoo.org/676948 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> eclass/qt5-build.eclass | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-)
