SUMMARY When passing --include-dependencies kdesrc-build does not consider building Qt 5. STEPS TO REPRODUCE 1. On fresh system without Qt set up kdesrc-build 2. Make sure to include kf5-qt5-build-include and qt5-build-include 3. Run kdesrc-build with for example the following options: --include-dependencies kate OBSERVED RESULT kdesrc-build bails because: ``` Unable to find qmake. This program is absolutely essential for building the modules: kded kcmutils kate kemoticons kactivities kiconthemes ktextwidgets kpackage phonon kplotting kdesignerplugin attica frameworkintegration modemmanager-qt khtml kauth knotifyconfig kitemmodels kdeclarative kxmlrpcclient kconfigwidgets oxygen-icons5 kpty karchive threadweaver kservice kdesu plasma-framework kwayland kbookmarks krunner knewstuff baloo kjobwidgets kjs kwallet kcompletion knotifications kconfig kjsembed bluez-qt kdnssd solid kpeople kglobalaccel sonnet kdbusaddons kdoctools kwidgetsaddons kmediaplayer kdelibs4support ktexteditor kdewebkit kross kidletime kcoreaddons polkit-qt-1 kfilemetadata prison kunitconversion networkmanager-qt qqc2-desktop-style kinit kactivities-stats kirigami kcodecs kitemviews kimageformats kparts syntax-highlighting kio kguiaddons kcrash ki18n kxmlgui breeze-icons kwindowsystem extra-cmake-modules. Please ensure the development packages for Qt are installed by using your distribution's package manager. ``` EXPECTED RESULT kdesrc-build builds Qt 5 first and then discovers the freshly built qmake (etc.) which let it continue with the kf5 deps of kate and eventually kate itself.
Am not sure if this is a missing bit of logic inside kdesrc-build itself or just project metadata which hasn't caught up with the fact kdesrc-build can take care of Qt 5 now.
This looks like a metadata issue. Tracking a fix for this at: https://phabricator.kde.org/D19171
It's both metadata and logic, to some extent. Qt5 is inherently a base dependency in the metadata itself, which kdesrc-build ignores and filters out because (at that time) Qt5 was meant to be provided by the base system. I'm really not sure I want to add "all of Qt5" as a mandatory kdesrc-build dependency, though there may be no other easier way to bootstrap the initial setup / "first run" process. But in your case you specifically add qt5-build-include and the script still aborts. This case should be made to work no matter what. I suspect that kdesrc-build is including qt5 in the build list, but not recognizing that qt5 will eventually come up with the missing qmake during the build. The check that fails here is made very early in the run to allow the user to fix without wasting an hour first on a 100+ failed git repo builds. In fact I think you may have already fixed this in your other commit to add Qt's paths to the search for essential build programs. I would avoid adding qt5 as a dependency as you're tracking in D19171 because that is meant for things that *have* to be built by kdesrc-build and/or build.kde.org, and I want to continue to support users who either build their own Qt 5 or use system packages. I'll comment there as well.
As I understand it now: 1.) There is a typo in the metadata Q instead q in qt5. This change is necessary to make kdesrc-build sit up and take notice when including qt5-build-include 2.) However if you do that and don't include qt5-build-include the qt5 dependency is likely to be visited multiple times with --include-dependencies because everything *does* now depend on qt5. - Speculation on my part here: because qt5 in that case does not resolve to a valid module/set kdesrc-build will not mark it as going to be built, but because it is depended upon multiple times now this means it trips the cycle detection logic. - Test case: can you construct a kdesrc-build command which includes two KDE projects but specifically omits a shared dependency from the build. If the theory holds, then the cycle detection logic should also trip in that case. 3.) Speculation on my part: kdesrc-build is silent about modules declared by metadata which it cannot resolve through the include files to actual modules. - Test case: inject a dummy does-not-exist module as dependency for something. If #2 holds we have a separate kdesrc-build bug on our hands here.
Okay so with updated understanding on my part: - We do not want to edit metadata because we're not the only consumer - Instead we want some 'magic' in kdesrc-build which: 1. Should detect whether or not qt5 module set/submodules are *available* 2. Should detect whether or not they are (implicitly) required 3. Should then update the internal dependency state in kdesrc-build to include qt5/submodules - This logic should trigger only in specific circumstances. Exact trigger TBD. E.g. only when using `--include-dependencies`? Any specific "but omit these module" type switches that might conflict and should presumably take precedence? Also: maybe add a simple `--try-building-qt5` switch for testing during development while we figure out the exact trigger conditions here?
Issue on invent.kde.org to track this bug: https://invent.kde.org/kde/kdesrc-build/issues/19
Git commit 7727d59c3c9cc7aaad7fe7ecddc3666e21722d17 by Johan Ouwerkerk. Committed on 24/02/2019 at 16:54. Pushed by ouwerkerk into branch 'fix-include-deps-qt'. Fix kdesrc-buid to consider 'special' dependencies configured in kdesrc-build.rc - Adjust the dependency resolver to no longer suppress 'special' dependencies if they can be built - Adjust the main application to determine which special dependencies have been configured through kdesrc-build.rc Fixes: #19 M +9 -4 modules/ksb/Application.pm M +10 -3 modules/ksb/DependencyResolver.pm https://invent.kde.org/kde/kdesrc-build/commit/7727d59c3c9cc7aaad7fe7ecddc3666e21722d17
Git commit 55c82a592f05b676b2b06504a409dbe37fb0cf33 by Johan Ouwerkerk. Committed on 24/02/2019 at 17:04. Pushed by ouwerkerk into branch 'fix-include-deps-qt'. Fix kdesrc-buid to consider 'special' dependencies configured in kdesrc-build.rc - Adjust the dependency resolver to no longer suppress 'special' dependencies if they can be built - Adjust the main application to determine which special dependencies have been configured through kdesrc-build.rc Fixes: #19 M +9 -5 modules/ksb/Application.pm M +10 -3 modules/ksb/DependencyResolver.pm M +2 -1 t/bug-394497-ignore-dep-module.t https://invent.kde.org/kde/kdesrc-build/commit/55c82a592f05b676b2b06504a409dbe37fb0cf33
Git commit 032f34bf270ef20897107473eb5878d5cedd7a23 by Johan Ouwerkerk. Committed on 24/02/2019 at 17:27. Pushed by ouwerkerk into branch 'break-cycle-detection-on-purpose'. Add a work-around for well known cycles in kde-build-metadata. Relates to: #22 Fixes: #19 M +41 -3 modules/ksb/DependencyResolver.pm https://invent.kde.org/kde/kdesrc-build/commit/032f34bf270ef20897107473eb5878d5cedd7a23