kdesrc-build issueshttps://invent.kde.org/sdk/kdesrc-build/-/issues2019-06-16T01:30:09Zhttps://invent.kde.org/sdk/kdesrc-build/-/issues/18Use Qt path when searching for qmake even if not in PATH2019-06-16T01:30:09ZMichael PyneUse Qt path when searching for qmake even if not in PATHWhen running kdesrc-build on a Fedora system where kdesrc-build has built and installed Qt5 to `/usr/local/qt5` (see !3), trying to run kdesrc-build to build something non-trivial fails immediately:
```
# kdesrc-build --stop-on-failur...When running kdesrc-build on a Fedora system where kdesrc-build has built and installed Qt5 to `/usr/local/qt5` (see !3), trying to run kdesrc-build to build something non-trivial fails immediately:
```
# kdesrc-build --stop-on-failure --include-dependencies dolphin --stop-after kcoreaddons
Updating kde-build-metadata (to branch master)
Updating sysadmin-repo-metadata (to branch master)
Unable to find qmake. This program is absolutely essential for building
the modules: extra-cmake-modules kcoreaddons attica.
Please ensure the development packages for
Qt are installed by using your distribution's package manager.
You can also see the
https://techbase.kde.org/Getting_Started/Build/Distributions page for
information specific to your distribution (although watch for outdated
information :( ).
* Aborting now to save a lot of wasted time.
* export KDESRC_BUILD_IGNORE_MISSING_PROGRAMS=1 and re-run (perhaps with --no-src)
* to continue anyways. If this check was in error please report a bug against
* kdesrc-build at https://bugs.kde.org/
```
qmake is definitely present at `/usr/local/qt5/bin`, and the qtdir option is correctly set. So kdesrc-build should be able to find this."First run" supportMichael PyneMichael Pyne2019-02-23https://invent.kde.org/sdk/kdesrc-build/-/issues/16Support Qt5 build and install2024-02-26T18:29:41ZMichael PyneSupport Qt5 build and installkdesrc-build used to support building Qt in addition to KDE. This changed with Qt 5 since it was a significantly different build system and most distributions packaged a recent enough Qt to permit using distro devel packages.
However we...kdesrc-build used to support building Qt in addition to KDE. This changed with Qt 5 since it was a significantly different build system and most distributions packaged a recent enough Qt to permit using distro devel packages.
However we now track to only requiring the current or 2 previous minor releases of Qt, which is often more recent than what popular stable or LTS distros might provide. Debian in particular, see #15 for an example.
To account for this kdesrc-build should support building, installing, and using git versions of Qt 5. Or at the very least tarball releases. There is a highly experimental way to do this with existing code that is floating around, but a dedicated build system using Qt 5's custom build framework seems more future-proof."First run" supportMichael PyneMichael Pyne2019-01-27https://invent.kde.org/sdk/kdesrc-build/-/issues/15Add required modules for Debian stable?2023-12-21T13:05:21ZMichael PyneAdd required modules for Debian stable?See [bug 402901](https://bugs.kde.org/show_bug.cgi?id=402901).
Basically, on Debian 9 (current stable) they get an error message when using `--initial-setup` that kdesrc-build doesn't know which packages to install for "linux". Which is...See [bug 402901](https://bugs.kde.org/show_bug.cgi?id=402901).
Basically, on Debian 9 (current stable) they get an error message when using `--initial-setup` that kdesrc-build doesn't know which packages to install for "linux". Which is accurate enough, since we haven't filled in the list for debian jessie yet.
However looking into this a bit further, debian jessie has only Qt 5.7, and we still don't officially support also building Qt in kdesrc-build after they switched to using submodules. I have experimental build-include files that can get through most of Qt but would need more work (and potentially code changes in kdesrc-build) to call production-quality.
See my question here is: Should we even be supporting stable/LTS distributions as a target for kdesrc-build? Or should we require a recent enough distro that it can at least provide a supported Qt?
@ngraham would appreciate your thoughts also."First run" supporthttps://invent.kde.org/sdk/kdesrc-build/-/issues/14--initial-setup uses relative directory in generated .kdesrc-buildrc2019-06-16T01:30:09ZMichael Pyne--initial-setup uses relative directory in generated .kdesrc-buildrcThe `%{base_dir}` below is replaced by the path to the running `kdesrc-build` when performing the `--initial-setup` command, however this replacement is relative, not absolute.
```shell
# You can include other files inline using the "in...The `%{base_dir}` below is replaced by the path to the running `kdesrc-build` when performing the `--initial-setup` command, however this replacement is relative, not absolute.
```shell
# You can include other files inline using the "include" command. We do this here
# to include files which are updated with kdesrc-build.
include %{base_dir}/kf5-qt5-build-include
```
This results in an error when running kdesrc-build using the generated rc-file, since the relative path is resolve against the directory the *rc-file* is hosted in, not where kdesrc-build is located.
Probably should just use absolute path instead."First run" supportMichael PyneMichael Pyne2018-12-31https://invent.kde.org/sdk/kdesrc-build/-/issues/9Try to install non-KDE build dependencies automatically2024-02-27T01:07:13ZMichael PyneTry to install non-KDE build dependencies automaticallySee https://bugs.kde.org/show_bug.cgi?id=402428
As title indicates, kdesrc-build should do what it can to automatically detect which non-KDE dependencies are missing and get those installed as well.
This is a critical enabler to making...See https://bugs.kde.org/show_bug.cgi?id=402428
As title indicates, kdesrc-build should do what it can to automatically detect which non-KDE dependencies are missing and get those installed as well.
This is a critical enabler to making it easier to onboard new contributors. There's a lot of commentary on the bug itself but I'd like to keep the narrative running here."First run" supportMichael PyneMichael Pynehttps://invent.kde.org/sdk/kdesrc-build/-/issues/3Add Arch support to --initial-setup2020-10-11T13:57:32ZMichael PyneAdd Arch support to --initial-setupAs per https://bugs.kde.org/show_bug.cgi?id=402484, Arch/Manjaro require `perl-io-socket-ssl` rather than whatever other package kdesrc-build is trying to pick up.As per https://bugs.kde.org/show_bug.cgi?id=402484, Arch/Manjaro require `perl-io-socket-ssl` rather than whatever other package kdesrc-build is trying to pick up."First run" supportMichael PyneMichael Pyne2019-01-05https://invent.kde.org/sdk/kdesrc-build/-/issues/2kdesrc-build-setup should setup ~/.bashrc2022-11-05T20:57:16ZMichael Pynekdesrc-build-setup should setup ~/.bashrcAnd while setting up ~/.bashrc, it should configure:
- PATH (to point to kdesrc-build, Plasma 5, Qt tools if not in PATH)
- MANPATH (for KDE man pages even if kdesrc-build is the only one)
- Really, all the things in `.setup-env` as doc...And while setting up ~/.bashrc, it should configure:
- PATH (to point to kdesrc-build, Plasma 5, Qt tools if not in PATH)
- MANPATH (for KDE man pages even if kdesrc-build is the only one)
- Really, all the things in `.setup-env` as documented at [our Get Involved](https://community.kde.org/Get_Involved/development) page."First run" supportMichael PyneMichael Pyne2019-01-11https://invent.kde.org/sdk/kdesrc-build/-/issues/1kdesrc-build should automatically enable --stop-on-failure2022-12-09T10:42:59ZMichael Pynekdesrc-build should automatically enable --stop-on-failureEspecially for first run scenario, when no subsequent modules will have ever been built and the user is potentially still having to find dependencies to install.
Detecting this is potentially difficult since the way metadata is handled ...Especially for first run scenario, when no subsequent modules will have ever been built and the user is potentially still having to find dependencies to install.
Detecting this is potentially difficult since the way metadata is handled is as if a user module were really successfully updated. It might be easiest just to look for whether any modules in the build list have never been part of persistent options, possibly with a threshold of 5 or higher or something."First run" supportMichael PyneMichael Pyne2019-01-11