While the help message says any unnamed options from the command line are passed as global or per-module options, that doesn't seem to work for me here. Reproducible: Always Steps to Reproduce: 1. ./kdesrc-build --help 2. ./kdesrc-build --async=false --stop-on-failure=true Actual Results: 1. [...] --<option>= Any unrecognized options are added to the global configuration, overriding any value that may exist. --<module>,<option>= Likewise, this allows you to override any module specific option from the command line. [...] 2. $ ./kdesrc-build --async=false --stop-on-failure=true Script started processing at Sat Jan 25 03:17:18 2014 * Downloading projects.kde.org project database... Runtime error: Unknown KDE project: --async=false Can't continue, so stopping now. Expected Results: kdesrc-build should run in async mode Obviously, the options are interpreted as modules to build, but that means GetOpt is sending those options to the non-option <> handler, which seems like a bug in GetOpt because Application.pm configures GetOpt with pass_through so those options should eventually be processed from $ARGV if I understand correctly.
Yes, this was broken in the large refactoring of the option-reading code, looks like I missed this one though. :-/
I took the issue to GetOpt::Long to see what they think and they suggest handling the options in <>, which makes sense (see the discussion at the bug report). https://rt.cpan.org/Public/Bug/Display.html?id=92462
Git commit 316a1b3361382ed5f460b673637dfc0c964934e1 by Michael Pyne. Committed on 26/01/2014 at 05:03. Pushed by mpyne into branch 'master'. cmdline: Restore support for arbitrary global option handling. The recent port to Getopt::Long broke the ability to use --foo=bar type of options (where <foo> is a global option name known to the build context). It also replaced the --module,foo=bar options with --set-module-option-value=module,foo,bar. While it's possible to use the latter syntax for global options (by using 'global' as the module name) that is undocumented and may not work forever. And either way, --foo options did use to work, and I noted it was broken in the refactor. So now that someone else has noticed I've reimplemented the feature. It's difficult to do entirely from within Getopt::Long since the documentation for that module gives you essentially one catch-all, which only supports *non-options*. So what I've done instead is to have kdesrc-build dynamically introspect its list of global options and flags and then add them to the list of valid options we pass to Getopt::Long. This also should mean that we don't need to pass 'pass_through' as an option to Getopt::Long anymore, though we'll see. This code path won't be used for options that already have a command line option (such as --async/--no-async) so that is still a misfeature compared to how it was before, but I guess it can't be perfect. =D I've tried to ensure that "flags" support the 'false' value to mean boolean false, but be careful to pass false or 0 if that's what you mean... specifying --dont-foo without giving it a value defaults it to true. M +44 -12 modules/ksb/Application.pm M +1 -1 modules/ksb/Updater/Svn.pm http://commits.kde.org/kdesrc-build/316a1b3361382ed5f460b673637dfc0c964934e1
As mentioned in the commit log I went a different way than using <> (since I didn't think <> supported anything that even *looked* like an option, or at least it I don't remember it doing so when I did the refactoring last month). I'm very impressed they responded so quickly to the bug report though. Please let me know if there's something still not working (which doesn't already have its own command-line option, that is). For things that *do* have their own command line option, you can theoretically use --set-module-value-option with a module of 'global' and kdesrc-build will blindly apply the change... ;)