kdesrc-build issueshttps://invent.kde.org/sdk/kdesrc-build/-/issues2024-02-27T02:27:04Zhttps://invent.kde.org/sdk/kdesrc-build/-/issues/135Feature request: Pause and automatically resume a build to build something el...2024-02-27T02:27:04ZNatalie Clariusnatalie_clarius@yahoo.deFeature request: Pause and automatically resume a build to build something else in the mean timeI often run into a situation like this:
1. Start my daily build of workspace
2. Actively work on a feature and need to build one module
3. "kdesrc-build is already running"
4. Quit the other process
5. Build my module over and over
6. D...I often run into a situation like this:
1. Start my daily build of workspace
2. Actively work on a feature and need to build one module
3. "kdesrc-build is already running"
4. Quit the other process
5. Build my module over and over
6. Done working on my feature or no need to compile for a while
7. Forget to resume my world build
What I would find useful:
3. "kdesrc-build is already running; other process was paused"
4. (no more intervention needed)
7. kdesrc-build automatically resumes the other build once it recognizes that there is no other build runninghttps://invent.kde.org/sdk/kdesrc-build/-/issues/87KDE's Qt 5 Patch Collection by default?2022-11-05T21:19:24ZAndrey ButirskyKDE's Qt 5 Patch Collection by default?Should we use KDE's Qt 5 Patch Collection by default to build Qt?
https://community.kde.org/Qt5PatchCollectionShould we use KDE's Qt 5 Patch Collection by default to build Qt?
https://community.kde.org/Qt5PatchCollectionhttps://invent.kde.org/sdk/kdesrc-build/-/issues/67Set to avoid switching git-branch if we had to stash changes, at least as a d...2021-09-12T00:17:06ZMichael PyneSet to avoid switching git-branch if we had to stash changes, at least as a default.From IRC:
```
[13:07] <CarlSchwan[m]> Is there a way for kdesrc-build to not try to switch branches and breaking stuff when stashing/poping?
[13:16] <mpyne> You can use --no-src to skip source updates completely. If it's doing an update...From IRC:
```
[13:07] <CarlSchwan[m]> Is there a way for kdesrc-build to not try to switch branches and breaking stuff when stashing/poping?
[13:16] <mpyne> You can use --no-src to skip source updates completely. If it's doing an update it's normally going to try to match the branch setup in the config file. There's not currently a separate option to just avoid switching branches but otherwise do an update (aside from the unwieldy --set-module-option-value to temporarly set the 'branch' option for the module bugging you)
[13:24] <ahmadsamir> {could/is} there {be} an option "if it's not on master or there are uncommitted changes, bail out" ?
[13:30] <CarlSchwan[m]> yeah, I usually do --no-src to just build, but this time it was as a part of a normal kdesrc-build to update all my packages
[13:30] <CarlSchwan[m]> it stashed my change from a branch, switched to master and then pop the stashed change. That broke a few things :/
[13:31] <CarlSchwan[m]> I didn't had that much unstaged changes so I could figure out a way to fix things
[13:34] <mpyne> Hmm, I can set it so that it doesn't switch branch unless there's nothing to stash. With a warning, of course.
```
Switch branches makes sense, and stashing local changes makes sense, but it probably doesn't make sense to switch branches *and* stash (and reapply) local changes.
If there are local changes *and* the branch is wrong, we should instead either:
1. Do nothing at all for the update (and complain to the user), or
2. Do the stashing drill but run the update for the existing branch rather than the configured one.
2 is probably better but might start with 1 as it is easier.https://invent.kde.org/sdk/kdesrc-build/-/issues/65Help developers setup git-blame for Frameworks modules2024-02-27T20:16:45ZMichael PyneHelp developers setup git-blame for Frameworks modulesSee @ivan's [comment](https://invent.kde.org/frameworks/kcoreaddons/-/issues/1#note_193124) from the [clang-format tracking issue](https://invent.kde.org/frameworks/kcoreaddons/-/issues/1):
> It would be cool to automatically do `git co...See @ivan's [comment](https://invent.kde.org/frameworks/kcoreaddons/-/issues/1#note_193124) from the [clang-format tracking issue](https://invent.kde.org/frameworks/kcoreaddons/-/issues/1):
> It would be cool to automatically do `git config --add blame.ignoreRevsFile .git-blame-ignore-revs` if there's a `.git-blame-ignore-revs` file in the repository - so that we can put clang-format commits to be automatically ignored when doing `git blame`.
I imagine we'd want to gate this behind a config for users who are uncomfortable with any git-config manipulation but for the rest of us this seems it would improve the developer experience.https://invent.kde.org/sdk/kdesrc-build/-/issues/34kdesrc-build API documentation2024-02-26T18:46:01ZJohan Ouwerkerkkdesrc-build API documentationAs we start to define more and proper APIs for the kdesrc-build server (mojolicious effort), we might want to document them. To quote @mpyne in !14
> How do you think this should be documented? There's a separate [`doc/source-reference`...As we start to define more and proper APIs for the kdesrc-build server (mojolicious effort), we might want to document them. To quote @mpyne in !14
> How do you think this should be documented? There's a separate [`doc/source-reference` folder](https://invent.kde.org/kde/kdesrc-build/tree/master/doc/source-reference) where we could put AsciiDoc but if this is meant to be API documentation then OpenAPI spec may be more appropriate. Whatever we do we're still only building up a wire format for the domain design here, we'd still want to document what is going into that DTO bundle.https://invent.kde.org/sdk/kdesrc-build/-/issues/25Support installing to /usr or another location requiring sudo access2019-03-24T18:38:26ZNate GrahamSupport installing to /usr or another location requiring sudo accessMy preferred workflow when developing in a KDE Neon VM is to overwrite the system packages and install everything to `/usr`. I currently use raw CMake and make for this, but I would like to switch to `kdesrc-build`. However I cannot, bec...My preferred workflow when developing in a KDE Neon VM is to overwrite the system packages and install everything to `/usr`. I currently use raw CMake and make for this, but I would like to switch to `kdesrc-build`. However I cannot, because it will fail to install to `/usr`:
```
cat ~/kde/src/log/2019-03-17-02/kiconthemes/install.log
# kdesrc-build running: 'make' 'install/fast'
# from directory: /home/dev/kde/build/kiconthemes
Install the project...
-- Install configuration: "RelWithDebInfo"
-- Installing: /usr/lib/x86_64-linux-gnu/cmake/KF5IconThemes/KF5IconThemesConfig.cmake
CMake Error at cmake_install.cmake:41 (file):
file INSTALL cannot copy file
"/home/dev/kde/build/kiconthemes/KF5IconThemesConfig.cmake" to
"/usr/lib/x86_64-linux-gnu/cmake/KF5IconThemes/KF5IconThemesConfig.cmake".
Makefile:79: recipe for target 'install/fast' failed
make: *** [install/fast] Error 1
```
It would be nice if it could run this with sudo in such a circumstance, since then the user could be prompted or could even set up passwordless sudo so the install step can be completed with no further user input required.https://invent.kde.org/sdk/kdesrc-build/-/issues/24Support creating Gitlab fork setup appropriately for a new feature2024-02-27T19:39:10ZMichael PyneSupport creating Gitlab fork setup appropriately for a new featureSimilar to #4, but for Gitlab instead of Phabricator.
Would need to use the [GitLab Projects API](https://docs.gitlab.com/ee/api/projects.html#fork-project) for this, most likely, requiring users to setup a personal API token.
More dis...Similar to #4, but for Gitlab instead of Phabricator.
Would need to use the [GitLab Projects API](https://docs.gitlab.com/ee/api/projects.html#fork-project) for this, most likely, requiring users to setup a personal API token.
More discussion was provided on the kde-devel mailing list in the [Gitlab Evaluation & Migration](https://markmail.org/message/tl6ppnmybhkd6bru) thread. In particular we'd want this to not just pre-emptively create a new fork every time a repo is cloned but would need to be manually requested.
This would permit users to work on a long-running feature branch and be able to push it back to our Gitlab infra even without being able to immediately push to the authoritative repository itself.https://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/12Support testing Gitlab merge requests from cmdline2024-02-27T01:40:48ZBhushan ShahSupport testing Gitlab merge requests from cmdlineInspired by #4
:smile:Inspired by #4
:smile:https://invent.kde.org/sdk/kdesrc-build/-/issues/11Setup common git config options for KDE project repositories2024-02-27T01:33:44ZMichael PyneSetup common git config options for KDE project repositoriesSome Git options may be useful for KDE's repositories and should be set by default. Along the lines of the existing support for options like `user.name` and `user.email` (which is already set globally but perhaps is better per-repo).
Es...Some Git options may be useful for KDE's repositories and should be set by default. Along the lines of the existing support for options like `user.name` and `user.email` (which is already set globally but perhaps is better per-repo).
Especially if we shift to Gitlab where branches will be created and deleted frequently, enforcing the use of `--prune` when we do `git fetch` in kdesrc-build would be a prudent default.
Of course, would need to be optional in case the user knows better than we do.https://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/7When using the --stop-on-failure argument, print contents of log file for fai...2024-02-26T18:23:34ZMichael PyneWhen using the --stop-on-failure argument, print contents of log file for failed build to the consoleSee https://bugs.kde.org/show_bug.cgi?id=402511
I like the idea, it even used to be in the very old versions of kdecvs-build. I had taken it out because the error formats had changed too much (and kdecvs-build was still meant to be run ...See https://bugs.kde.org/show_bug.cgi?id=402511
I like the idea, it even used to be in the very old versions of kdecvs-build. I had taken it out because the error formats had changed too much (and kdecvs-build was still meant to be run from `cron` back in the day!). But the format is stable and most kdesrc-build usages are interactive now.Michael PyneMichael Pyne2019-01-19https://invent.kde.org/sdk/kdesrc-build/-/issues/6Prefer the flat directory structure over the hierarchical project structure2019-02-09T03:09:37ZMichael PynePrefer the flat directory structure over the hierarchical project structureSee https://bugs.kde.org/show_bug.cgi?id=402536 (and from a much earlier time, commit 3440790441d0aa649657ddb5cfc46fe422187857 by afiestas)
I've always aesthetically preferred the hierarchical structure but given how unhelpful it is for...See https://bugs.kde.org/show_bug.cgi?id=402536 (and from a much earlier time, commit 3440790441d0aa649657ddb5cfc46fe422187857 by afiestas)
I've always aesthetically preferred the hierarchical structure but given how unhelpful it is for new users, and problems that have popped up even for myself every so often (like when a module moves), it's time to acknowledge that it's better to prefer function to form here.
Also the technical limitation I was worried about when I developed this structure doesn't actually apply (that is, the sysadmins don't permit multiple KDE projects to resolve to the same git repository name for other reasons, so I don't have to worry about there being two modules that map to the same 'flat name').
Fixing this for new users is as simple as changing the default option. But I'd want to find a way to automatically move over source/build directories for existing users first.Michael PyneMichael Pyne2019-01-26https://invent.kde.org/sdk/kdesrc-build/-/issues/5Option to print all needed environment variables for manual cmake/build2024-02-26T14:13:22ZMichael PyneOption to print all needed environment variables for manual cmake/buildAs reported at https://bugs.kde.org/show_bug.cgi?id=394196
> Sometimes one wants to build or rebuild a KDE module without using kdesrc-build. It would be helpful if kdesrc-build had an option like "--printenv" which prints all needed en...As reported at https://bugs.kde.org/show_bug.cgi?id=394196
> Sometimes one wants to build or rebuild a KDE module without using kdesrc-build. It would be helpful if kdesrc-build had an option like "--printenv" which prints all needed environment variables needed to run a manual build. E.g.:
CMAKE_PREFIX_PATH=...
...=...
> This would be helpful to understand what kdesrc-build does under the hood and it could be used in a sourced bash script to setup those variables consistently.
I like the idea of being able to introspect what kdesrc-build is doing (e.g. using the `--query` option that exists already). Just need to figure out how to do it...Michael PyneMichael Pyne2019-01-12https://invent.kde.org/sdk/kdesrc-build/-/issues/4Support testing Phabricator patches from cmdline2024-02-27T19:39:11ZMichael PyneSupport testing Phabricator patches from cmdlineSee https://bugs.kde.org/show_bug.cgi?id=402538, Nate gives a very useful example of a developer aid we could provide, e.g.:
kdesrc-build konsole --patch D17643 --include-dependencies --stop-on-failure
Some questions as always (e.g...See https://bugs.kde.org/show_bug.cgi?id=402538, Nate gives a very useful example of a developer aid we could provide, e.g.:
kdesrc-build konsole --patch D17643 --include-dependencies --stop-on-failure
Some questions as always (e.g. whether and when to revert the patch) but could be an easy win.Michael PyneMichael Pyne2019-01-26https://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-11