From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11232 invoked by alias); 31 Aug 2016 06:46:00 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 39138 Received: (qmail 8015 invoked from network); 31 Aug 2016 06:45:59 -0000 X-Qmail-Scanner-Diagnostics: from ioooi.vinc17.net by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(92.243.22.117):SA:0(-1.5/5.0):. Processed in 0.183129 secs); 31 Aug 2016 06:45:59 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: vincent@vinc17.net X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at vinc17.net does not designate permitted sender hosts) Date: Wed, 31 Aug 2016 08:45:55 +0200 From: Vincent Lefevre To: zsh-workers@zsh.org Subject: Re: buggy configure completion - when both --enable-foo and --disable-foo are listed Message-ID: <20160831064555.GB15435@zira.vinc17.org> Mail-Followup-To: zsh-workers@zsh.org References: <20160830232332.GA23779@zira.vinc17.org> <20160831030304.GD30557@fujitsu.shahaf.local2> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160831030304.GD30557@fujitsu.shahaf.local2> X-Mailer-Info: https://www.vinc17.net/mutt/ User-Agent: Mutt/1.7.0-6766-vl-r91193 (2016-08-17) 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 - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)