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

Hello bug-standards readers,
Autoconf 2.66 added '+' to the set of allowed characters in So, my question is: could standards.texi document the set of allowed
characters?
Current Autoconf has -+. mapped to - and otherwise wants characters
eligible for shell variable names; but you may want to just allow more
of them?
Thanks,
Ralf

Autoconf 2.66 added '+' to the set of allowed characters in So, my question is: could standards.texi document the set of allowed
characters?
Can you make a proposal?
Current Autoconf has -+. mapped to - and otherwise wants characters
eligible for shell variable names; but you may want to just allow more
of them?
What's the advantage of allowing more characters?
Thanks,
k

* Karl Berry wrote on Mon, Aug 02, 2010 at 12:00:21AM CEST:
Easier to remember option names? Dunno.
Cheers,
Ralf

So gnulib could have Easier to remember option names? Dunno.
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. Overall, my thought would
be to allow as few characters as possible. [Personally I think - should be used in preference to - wherever possible
in option names, for the reason above: easier for users to remember if
there are fewer variances.
Sure; later.
Thanks. Will await :).
karl

[ adding bug-gnulib ]
* Karl Berry wrote on Tue, Aug 03, 2010 at 01:11:47AM CEST:
decision in Autoconf?
The switch hasn't been so long ago, so presumably reverting now is not
as costly as doing it later.
document it so (non-Autoconf) configure authors and macro authors know.
Thanks,
Ralf

Hello Karl,
1) For 2) For many libraries, 3) 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.
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
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 - 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++ - 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 'Bruno

I was merely musing on my experiences in that initial reply, not making
final proclamations or anything. Sorry if I gave that impression. I
realize there are advantages to allowing +, which you have ably
enumerated :).
I'm ok with proposing to rms that + be allowed, along with: Isn't this an indication that *not* allowing the '+' character makes
it hard for the user to guess?
Certainly. If + had been universally supported in all needed contexts
from the beginning, that would have been much better. We don't live in
that world, though.
In my experience, '+' characters cause no more hassles than '-' and '.'.
I was referring exactly to the endless confusion/speculation by users
about whether + is used literally, or xx, or pp, or plusplus, or some
other variation. Perhaps allowing + in Just to mention it: of course + is special in one way that - and . are
not: it's used to encode a space in some cases in url's. (This doesn't
seem like a serious drawback to me as far as Thanks,
karl

Hello Bruno,
* Bruno Haible wrote on Wed, Aug 04, 2010 at 11:24:19PM CEST:
This is not an option IMVHO, because it has the very distinct
disadvantage that you cannot build packages together with the same
configure options when one package accepts + and another barfs.
You just lost that one big positive feature that a detailed configure
API in GCS can bring you: consistency, stackability.
And since not all configure scripts in the world are written by
autoconf, it is not an option to just hide this new feature in Autoconf
either.
I don't disagree to adding the +, but to be honest, I don't think your
argumentation is sound: you should be addressing the question why
destroying compatibility is acceptable in this case, rather than why the
new feature is desirable. The latter is fairly obvious, but the former
might be a burden that others might have to carry.
Thanks,
Ralf