bug-gnulib
[Top][All Lists]
Advanced

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

Re: characters allowed in --enable-*/--with-*


From: Bruno Haible
Subject: Re: characters allowed in --enable-*/--with-*
Date: Wed, 4 Aug 2010 23:24:19 +0200
User-agent: KMail/1.9.9

Hello Karl,

> >     Autoconf 2.66 added '+' to the set of allowed characters in --enable-*
>
> Why?

There were three reasons behind my proposal on bug-autoconf on 2010-03-13:

  1) For --enable/--disable: So that programs can use --enable-c++,
     which is easier for the user to remember than either --enable-cxx
     or --enable-cpp.

  2) For many libraries, --with options are used to specify the location
     of the library on the file system. This is done by GCC (see
     <http://gcc.gnu.org/install/configure.html>, which specifies e.g.
       --with-libart-prefix=PFX
       --disable-libarttest
     but also by packages which use the gnulib 'havelib' module.
     There are several libraries installed on a typical system that contain
     plus signs:
        libg++
        libFLAC++
        libgpgme++
        libncurses++
     Why should a user not be able to type --with-libg++-prefix=PFX ?

  3) --with options are also used to designate programs, and there are
     programs that contain plus signs in their name. Some packages have
     options
        --enable-bison-regeneration
        --enable-flex-regeneration
     but without the proposal they were unable to have
        --enable-flex++-regeneration
     Yes, there is a program /usr/bin/flex++.

Btw, there is also a GNU package called "GNU Common C++". In summary,
it is not rare to have package names and library names that contain plus
signs.

> (That ++ causes endless hassle everywhere.)

In my experience, '+' characters cause no more hassles than '-' and '.'.
Neither of these characters are globbing characters in the shell. All
three characters have a special meaning in regular expressions - but
'-' and '.' were already supported in --enable and --with options, and
known to not causes hassles.

> I'd say the opposite: allowing lots of "random" characters makes it
> harder for users to know/guess/remember option names.  Aside from
> technical issues with quoting and the like.

I agree that characters which interfere with shell globbing (like '?',
'*', ' ') or quoting should be avoided. But a '+' character is not
more dangerous than a '.' or '-' character.

Regarding what the users have to guess or remember:

  - For --enable-c++ you suggest to replace '+' with 'plus'.

  - Among the GCC installation options at
    <http://gcc.gnu.org/install/configure.html>
    there is an option --enable-build-with-cxx. So they decided that
    replacing '+' with 'x' was the most natural.

  - The GNU Common C++ project is to be found under 'commoncpp' on
    www.gnu.org and ftp.gnu.org. And there is a symlink
    commonc++ -> commoncpp, apparently because users would have to guess
    the transliteration from '+' to 'p'.

Isn't this an indication that *not* allowing the '+' character makes
it hard for the user to guess? And that allowing the '+' character will
make it *easier* for the users?

If I can't convince you, then I would propose to be silent about this
question in the GNU standards for the moment, and revisit the issue in
five years. In five years, we'll be able to tell whether allowing a
configure option '--enable-c++' in programs will have caused "hassle
everywhere".

Bruno



reply via email to

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