On Sun, 01 Jun 2014 00:30:02 +0200 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Am 30.05.2014 00:52 schrieb Stefan Tauner:
This code exists thanks to food for thought from Urja Rannikko.
Signed-off-by: Stefan Tauner stefan.tauner@alumni.tuwien.ac.at
Interesting, to say the least. The default parameter only applies if -p is not specified at all, so there are no unexpected side effects. The only complaint I have (except the question "who would want to use that") is that you can run make CONFIG_DEFAULT_PROGRAMMER_ARGS="foobar" without having to specify CONFIG_DEFAULT_PROGRAMMER as well. CONFIG_DEFAULT_PROGRAMMER_ARGS won't have any effect in that case during runtime, but that might surprise someone who specified it.
Hm. Maybe I should really ask who would want to use that... it's obviously not a feature distributions would use, although it seems some of them use CONFIG_DEFAULT_PROGRAMMER to keep the behavoir unchanged compared to previous releases.
Not opposed to it, but not really convinced either.
Urja is using a variation of this patch for about half a year. The rationale is quite strong IMHO: If you want to use a default programmer and this programmer requires some parameters (and always the same parameters), then the default programmer alone does not help you much: you can't specify the options without specifying the programmer too! So actually it does really make sense for pretty much everyone that uses the default programmer (other than those using the default programmer to work around our -p internal change). Well, that's probably Urja alone for now :)
Regarding your complaint of PROG_ARGS w/o PROG... I don't think that justifies more code, but if you insist I can add a check for that, that warns if the ARGS are set but the PROG is still INVALID.