Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: buggy configure completion - when both --enable-foo and --disable-foo are listed
- X-seq: zsh-workers 39138
- From: Vincent Lefevre <vincent@xxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: buggy configure completion - when both --enable-foo and --disable-foo are listed
- Date: Wed, 31 Aug 2016 08:45:55 +0200
- In-reply-to: <20160831030304.GD30557@fujitsu.shahaf.local2>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mail-followup-to: zsh-workers@xxxxxxx
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <20160830232332.GA23779@zira.vinc17.org> <20160831030304.GD30557@fujitsu.shahaf.local2>
On 2016-08-31 03:03:04 +0000, Daniel Shahaf wrote:
> It thinks --enable-gmp-internals takes an argument. This seems to
> happen whenever there's an "=" sign on that line of the --help output.
[...]
> Line 143 is in the handling of "--help" parsing. The other lines look
> for --foo=[…]:… specs. The pattern in 266/268 appears to match the
> '=' sign even though it's in the second colon-separated field, where it
> doesn't denote a mandatory argument.
>
> I'm guessing the pattern match on lines 266/268 should be fixed, but I'm
> not sure how.
Another example is the following with autoconf-generated configure:
--enable-silent-rules less verbose build output (undo: "make V=1")
--disable-silent-rules verbose build output (undo: "make V=0")
Moreover, still with autoconf-generated configure, --enable-*
options always accept an argument. More precisely:
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
--enable-FEATURE[=ARG] include FEATURE [ARG=yes]
though actually, one generally doesn't provide one (anyway, one cannot
complete on arguments since one doesn't know what is accepted).
I'd say that the rules should be:
* If one just has the option, e.g.
--enable-gmp-internals enable use of GMP undocumented functions [default=no]
(anything after a space following the option being ignored), the
completion shouldn't assume that the user will give an argument,
though he might add one after completing.
* If there is a "=" just after the option, e.g.
--with-mulhigh-size=NUM internal threshold table for mulhigh
then an argument is assumed.
* If there is an explicit *optional* argument in the --help output,
e.g.
--enable-shared[=PKGS] build shared libraries [default=yes]
--enable-static[=PKGS] build static libraries [default=yes]
(as generated by libtool), then this should also be taken into
account, but I think that this should be like in the first case.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Messages sorted by:
Reverse Date,
Date,
Thread,
Author