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.

Reply via email to