Re: [PATCH 2/3] parseopt: introduce OPT_RECURSE to specify shared options

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Nov 5, 2007, 16:15 UTC
Message-ID: <alpine.LFD.0.999.0711050755340.15101@woody.linux-foundation.org>
In-Reply-To: <Pine.LNX.4.64.0711051340490.4362@racer.site>

On Mon, 5 Nov 2007, Johannes Schindelin wrote:

> 
> After kicking this around a bit more on IRC, we had another idea.  Instead 
> of introducing OPT_RECURSE(), do something like OPT__QUIET(), only this 
> time in diff.h: ....

I think the preprocessor approach would tend to be simpler, which is an advantage. But whichever approach is chosen, I think one important issue is to make sure that options that *hide* other options are correctly handled in the help printout..

We have a few cases where a "recursive" option is hidden. For example, the option "-n" can mean different things in different contexts: in git-format-patch, for example, the "-n" is handled *before* calling setup_revisions() and allt he normal revision flags, which means that the format-patch -specific meaning of "-n" overrides the normal "revision" meaning.

I suspect that in this kind of situation, it's actually easier to have a single linear array of options, because the option parser can just walk back and check "oh, I already saw this short option, so I should not output it as documentation because this version of it is hidden by the earlier one".

But that's an implementation issue. The same certainly *can* be done with a recursive setup, just passing a linked list of what the earlier levels were (which is what we do in other places). And it's not like the recursion is going to be very deep or complex.

		Linus