chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] Ambiguity in csc's command line options (#1193)


From: Peter Bex
Subject: Re: [Chicken-hackers] Ambiguity in csc's command line options (#1193)
Date: Sun, 24 May 2015 00:41:02 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Sat, May 23, 2015 at 10:33:20PM +0000, Mario Domenech Goulart wrote:
> Hi,
> 
> I've filed https://bugs.call-cc.org/ticket/1193 , which reports an isue
> about ambiguity in csc's command line options.
> 
> Maybe CHICKEN 5 can be a good opportunity to fix that issue, since
> backward compatibility is not such a big compromise,
> 
> Some options we have:
> 
> 1. require a space between the parameter and the argument.  So, `-lfoo'
>    would be an invalid option and `-l foo' would mean "link against
>    libfoo".  -lfa2 would be a valid option, and would NOT mean "link
>    against libfa2".
> 
> 2. support GNU-style command line options, that is, --<long> and -<l>.
>    Then we'd have --lfa2 to ask chicken to perform an additional
>    lightweight flow-analysis pass and -lfa2 to link against libfa2.
> 
> Any other ideas?  Comments?

I'd be in favor of switching to a more "standard" GNU getopt-like
approach where there's a clear distinction between single letter
options without arguments (which can be grouped together like -abc
which means -a -b -c), single letter options with arguments (which
allow an optional space so you'd have -lfoo and -l foo which mean
the same) and multi-letter "long" options, in the GNU style like
--foo which is its own option.  If it accepts an argument, it must
be separated with a space like --lfa2 or --library curses as an
alternative to -lcurses.

We could paint a bikeshed about whether --library=curses should
be acceptable or not.

Cheers,
Peter

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]