Hello Bruno,
* Bruno Haible wrote on Wed, Aug 04, 2010 at 11:24:19PM CEST:
> If I can't convince you, then I would propose to be silent about this
> question in the GNU standards for the moment,
This is not an option IMVHO, because it has the very distinct
disadvantage that you cannot build packa
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: -_.A-Za-z
I wasn
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 ei
[ adding bug-gnulib ]
* Karl Berry wrote on Tue, Aug 03, 2010 at 01:11:47AM CEST:
> So gnulib could have --enable-c++.
>
> I guess I missed some discussion on bug-gnulib. Overall, "cplusplus"
> seems like it would have been simpler/more customary. (That ++ causes
> endless hassle everywhere
So gnulib could have --enable-c++.
I guess I missed some discussion on bug-gnulib. Overall, "cplusplus"
seems like it would have been simpler/more customary. (That ++ causes
endless hassle everywhere.)
Easier to remember option names? Dunno.
I'd say the opposite: allowing lots of "ran
* Karl Berry wrote on Mon, Aug 02, 2010 at 12:00:21AM CEST:
> Autoconf 2.66 added '+' to the set of allowed characters in --enable-*
>
> Why?
So gnulib could have --enable-c++.
> So, my question is: could standards.texi document the set of allowed
> characters?
>
> Can you make a pr
Autoconf 2.66 added '+' to the set of allowed characters in --enable-*
Why?
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 variab
