365813 2016-07-18 13:00:02 +0000 options doesn't work for module-sets 2024-05-10 09:17:13 +0000 1 1 6 Developer tools kdesrc-build general Git Compiled Sources Linux RESOLVED FIXED NOR wishlist --- 1 faure mpyne https://invent.kde.org/sdk/kdesrc-build/-/commit/dc70f55c7dc6e494fbc8a16b94e48111a59b5740 16.08 0 oldest_to_newest 1608888 0 faure 2016-07-18 13:00:02 +0000 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. 1609997 1 100253 mpyne 2016-07-22 23:30:12 +0000 Created attachment 100253 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? 1610160 2 faure 2016-07-24 09:05:49 +0000 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). 1610232 3 mpyne 2016-07-24 17:03:42 +0000 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 2318741 4 mpyne 2024-05-10 09:17:13 +0000 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 100253 2016-07-22 23:30:12 +0000 2016-07-22 23:30:12 +0000 Patch options matching named module-sets into module options kdesrc-build-mset-options.patch text/plain 816 mpyne ZGlmZiAtLWdpdCBhL21vZHVsZXMva3NiL01vZHVsZVJlc29sdmVyLnBtIGIvbW9kdWxlcy9rc2Iv TW9kdWxlUmVzb2x2ZXIucG0KaW5kZXggNjY5NmE0OC4uMGNmZDNjNiAxMDA2NDQKLS0tIGEvbW9k dWxlcy9rc2IvTW9kdWxlUmVzb2x2ZXIucG0KKysrIGIvbW9kdWxlcy9rc2IvTW9kdWxlUmVzb2x2 ZXIucG0KQEAgLTc1LDExICs3NSwxNSBAQCBzdWIgX2FwcGx5Q21kbGluZU9wdGlvbnMKIAogICAg IGZvcmVhY2ggbXkgJG0gKEBtb2R1bGVzKSB7CiAgICAgICAgIG15ICRuYW1lID0gJG0tPm5hbWUo KTsKKyAgICAgICAgbXkgJG1vZHVsZVNldE5hbWUgPSAkbS0+bW9kdWxlU2V0KCktPm5hbWUoKTsK IAogICAgICAgICAjIFJlbW92ZSBhbnkgb3B0aW9ucyB0aGF0IHdvdWxkIGludGVyZmVyZSB3aXRo IGNtZGxpbmUgYXJncwogICAgICAgICBkZWxldGUgQHskbS0+e29wdGlvbnN9fXtAY21kbGluZUFy Z3N9OwogCi0gICAgICAgICMgUmVhcHBseSBtb2R1bGUtc3BlY2lmaWMgY21kbGluZSBhcmdzCisg ICAgICAgICMgUmVhcHBseSBtb2R1bGUtc3BlY2lmaWMgY21kbGluZSBhcmdzIChtb2R1bGUtc2V0 IGZpcnN0KQorICAgICAgICBpZiAoJG1vZHVsZVNldE5hbWUgJiYgZXhpc3RzICRzZWxmLT57cGVu ZGluZ09wdGlvbnN9LT57JG1vZHVsZVNldE5hbWV9KSB7CisgICAgICAgICAgICAkbS0+c2V0T3B0 aW9uKCV7JHNlbGYtPntwZW5kaW5nT3B0aW9uc30tPnskbW9kdWxlU2V0TmFtZX19KTsKKyAgICAg ICAgfQogICAgICAgICAkbS0+c2V0T3B0aW9uKCV7JHNlbGYtPntwZW5kaW5nT3B0aW9uc30tPnsk bmFtZX19KTsKICAgICB9CiAK