| Summary: | options doesn't work for module-sets | ||
|---|---|---|---|
| Product: | [Developer tools] kdesrc-build | Reporter: | David Faure <faure> |
| Component: | general | Assignee: | Michael Pyne <mpyne> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | ||
| Priority: | NOR | ||
| Version: | Git | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/sdk/kdesrc-build/-/commit/dc70f55c7dc6e494fbc8a16b94e48111a59b5740 | Version Fixed In: | 16.08 |
| Sentry Crash Report: | |||
| Attachments: | Patch options matching named module-sets into module options | ||
Created attachment 100253 [details]
Patch options matching named module-sets into module options
The attached patch does what you want in my testing. I'm not sure if this simple change is exactly the best way to go though.
Having a separate module-set-options seems needlessly user-hostile (though in fairness it is consistent with the way option handling has evolved in the code). It wouldn't be hard to adjust the config file parser to warn (or throw error) if a module-set and module both have the same name, and that would ensure that a plain 'options' block works for both..... except that 'options' is also meant to work in the case of modules that are not known about in the rc-file parser, but only become visible later (e.g. if you name a module-set 'juk' but perform a 'use-modules kde/kdemultimedia' in a separate module-set, you'd have two entities named "juk" that could have options applied).
That's somewhat contrived of course, I'm just worried that "options foo ... end options" could end up meaning 2 separate things depending only on events that happen at runtime.
With all that said, this does seem to work and they say that the perfect is the enemy of the good, so maybe it's best to integrate it and wait for problems (if any) before worrying too much?
Thanks for the patch, much appreciated, I needed this to be able to work on kdepim ;)
Tested to work, please push the change.
"could end up meaning two separate things" is already a problem, I think, when having a module and a module-set with the same name. For instance, kf5-extragear-build-include says
module-set kmymoney
repository kde-projects
use-modules kdiagram alkimia kmymoney
end module-set
What happens when doing "kdesrc-build kmymoney" is that it builds the module-set, which also means one can't *just* rebuild the module alone. And, with this patch, "options kmymoney" would always apply to the whole module-set rather than just one module. It seems to me that module-set-options wouldn't be ideal because it would fix the 2nd issue while "kdesrc-build kmymoney" would still be ambiguous.
The obvious best solution to that problem is to not use module names for module-sets, since this makes us lose flexibility. Therefore I would rename these badly named module sets ("akonadi" could very well be "kde-pim-akonadi", in fact that module set name is useless, maybe "module" would have been enough? (I forgot it that would use branch-group settings...)).
And then if we make sure that we don't have conflicts anymore (=> your suggestion of a warning sounds good), we can keep using "options" for both (so this patch is fine).
Git commit c3081844077eb53adb8a9d58c8a3e3dc66921cee by Michael Pyne. Committed on 24/07/2016 at 17:01. Pushed by mpyne into branch 'master'. Allow 'options' groups to apply to named module-sets. This makes it more convenient to work with baseline configurations (that are 'include'd) without changing the upstream configuration. Still to do: add a warning when modules and module-sets end up sharing the same name somehow. FIXED-IN:16.08 M +9 -1 doc/index.docbook M +5 -1 modules/ksb/ModuleResolver.pm http://commits.kde.org/kdesrc-build/c3081844077eb53adb8a9d58c8a3e3dc66921cee Git commit dc70f55c7dc6e494fbc8a16b94e48111a59b5740 by Michael Pyne. Committed on 24/07/2016 at 17:01. Pushed by ashark into branch 'docbook_historied_per_file'. Allow 'options' groups to apply to named module-sets. This makes it more convenient to work with baseline configurations (that are 'include'd) without changing the upstream configuration. Still to do: add a warning when modules and module-sets end up sharing the same name somehow. FIXED-IN:16.08 Original commit: c3081844 https://invent.kde.org/sdk/kdesrc-build/-/commit/c3081844077eb53adb8a9d58c8a3e3dc66921cee M +1 -1 doc/index.docbook M +8 -0 doc/kdesrc-buildrc/kdesrc-buildrc-overview.docbook https://invent.kde.org/sdk/kdesrc-build/-/commit/dc70f55c7dc6e494fbc8a16b94e48111a59b5740 |
I would like to keep using branch-group kf5-qt5 (for KF5 itself, for the workspace, for most apps, etc.) but I would like to switch to Applications/16.08 for the kde pim stack. Reproducible: Always Steps to Reproduce: The modules that make up "kde pim" are a very large number (hmm what's the proper English sentence for this?). They are defined in 3 module-sets in kf5-kdepim-build-include: akonadi kde-pimlibs kde-pim Therefore my attempt, to avoid forking kf5-kdepim-build-include, was to write, in my kdesrc-buildrc: include extragear/utils/kdesrc-build/kf5-qt5-build-include options akonadi branch Applications/16.08 end options options kde-pimlibs branch Applications/16.08 end options options kde-pim branch Applications/16.08 end options Actual Results: This works well for akonadi, because that's the module name, but not for the others, e.g. kdesrc-build kde-pimlibs shows Building kcontacts from kde-pimlibs (1/43) Updating kcontacts (to branch master) Expected Results: Could "options" for a module-set be applied to all the modules of the module-set ? Alternatively you might prefer a more explicit module-set-options, don't know what fits best with kdesrc-build's overall design for modules and module-sets.