[pacman-dev] [PATCH] scripts/library: rewrite parse_options

[Allan McRae]

On 18/08/11 08:27, Dan McGee wrote:
> On Thu, Jul 21, 2011 at 3:40 PM, Dave Reisner<d at falconindy.com>  wrote:
>> In addition to being what I feel is a cleaner and faster implementation,
>> we avoid the use of eval by normalizing option arguments into a global
>> array which is then set after a successful call to parse_options.
>>
>> This trims out the idea of having multiple arguments to a single option,
>> making our parsing algorithm a little more sane. We never took advantage of
>> this in makepkg (for the one option that feasibly supports it), and I
>> think we've overlooked a much simpler solution in pacman-key. Since
>> actions are limited to 1 at a time the leftover positional parameters
>> become the keys or keyfiles which are acted upon.
>>
>> Also added is a new test directory test/scripts with a harness for
>> parse_options, run as part of make check.
>>
>> Signed-off-by: Dave Reisner<dreisner at archlinux.org>
>> ---
>> Thoughts? I know Allan wasn't quite sold on this, as the downside is that we
>> sort of pigeonhole ourselves into using the non-optional parameter as arguments
>> to our action. This has zero effect on makepkg.
>>
>> I've also thought to add --option=arg syntax parsing, but I'm not sure we need
>> this.
>
> Allan, was deferring to you on this.


Well, I was deferring to you as Dave is right that I was never sold on 
this...

Unless I am missing something, this does have a minor effect on makepkg. 
  In git "makepkg --pkg foo bar" builds only foo and bar from a split 
package.  I guess with this patch we would have to quote the package 
names in some way (like is needed on the current maint release).  So we 
would need to revert changes made to the makepkg documentation when the 
multiple arguments stuff was added.

But my main issue is that we lose the ability to specify multiple 
arguments with optional parameters.  We do not use this anywhere at the 
moment, so it is not a big loss but that is not to say we will never use 
it in the future.

Basically, I am not sure what the actual advantage of rewriting this is...

Allan