https://bugs.kde.org/show_bug.cgi?id=366594
Michael Pyne <mp...@kde.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #4 from Michael Pyne <mp...@kde.org> --- Yes, it's expected that it would mask the existing option. It wouldn't *have* to but it's hard to know ahead of time which options the user would prefer to be overwritten by a later declaration and which options should instead append to the existing option (or otherwise nest). Maybe it would be possible to extend the existing syntax for referring to global options to refer to existing use-modules / ignore-modules settings... As far as the error you've encountered, it's because "options" is only read to override a module-set if it's already seen a module-set by a matching name... I'll need to think of how to do this better so that it's possible to carry around an "options" block in a configuration file even if it doesn't end up referring to a module or module-set due to the way the include declarations are handled. -- You are receiving this mail because: You are watching all bug changes.