autoconf-patches
[Top][All Lists]
Advanced

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

Re: 10-forbidden-tokens-in-comments.patch


From: Akim Demaille
Subject: Re: 10-forbidden-tokens-in-comments.patch
Date: 18 Jan 2001 10:36:58 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Crater Lake)

>>>>> "Bernard" == Bernard Dautrevaux <address@hidden> writes:

Bernard> I'm not sure I agree with that patch; it's arguable to detect
Bernard> all "\<_?A[AZ]_[A-Za-z0-9_]*" patterns in the configure code,
Bernard> but checking these even in comments will be a *huge* burden
Bernard> for migration to the new autoconf.

Anyway, the presence of macro names in the output is itself arguable.

Bernard> I would in fact favor a patch that will accept
Bernard> inconditionnaly these macro-looking identifiers not only in
Bernard> comments, but also in strings, so that I can have an

Bernard>        AC_MSG_WARNING([Beware that AF_DECNET was not a valid
Bernard> domain on this machine])

I would not.  These places are just *less likely* to be affected by a
serious bug, but they are just another place to be screwed.  I'll keep
on strengthening autoconf intolerance.

Bernard> somewhere in my tests, without having to do special hacking
Bernard> with m4_i_dont_know_what(AF_DECNET)... Clearly (although it's
Bernard> not very useful in a distributed package) I could even add
Bernard> AC_MSG_WARNINGs about some AC_SOMETHING macro that I would
Bernard> like to eliminate but want for a while to just be warned if
Bernard> it is still called (I say called, not used, intentionally:
Bernard> the macro may be used, but protected by a test that finally
Bernard> decide never to call it).

Sorry, but this is the perfect example of what makes just no sense.
If you have to complain about a macro, it's AC_FATAL, not
AC_MSG_ERROR.

Bernard> The problem raised in another message about AF_INET used in C
Bernard> code is a bit more complicated, as I may want to obtain C
Bernard> code by expansion of some autoconf macro, and then detection
Bernard> of unexpanded macro is intersting there.  I just think that
Bernard> reserving all A[A-Z] digrams is a lot too picky; the example
Bernard> of AF_xxxx is a good example: there is litterally tens of
Bernard> these cpp macros out there starting by AF_ (and AI_), so
Bernard> using an autotool macro starting by AF_ is at least dubious
Bernard> and surely will cause problems.... So we should probably try
Bernard> to define which Ax_ digrams are ALLOWED to de AC_DEFUN'ed
Bernard> rather that forbidding use of ANY Ax_starting macro.

If there is a real demand for it, I might release AF, and AI, but
frankly, I don't like this.

Bernard> And forgive me, but looking for all such
Bernard> macro-like-references and changing the "_" by "-" to avoid
Bernard> the autoconf warning is a lot too hacky to be satisfying :-)

The presence of macro names in the output is not satisfying.  Macro
names are very logically commented by dnl comments, not `#' comments.
Autoconf itself is not very right agreed.

Using `-' is just a means to tell other people ``hey, I know what I'm
doing'', just like you sometimes write /* nothing */ in C for the
other guys to understand what you do, just like you write /* FALLTHRU
*/ to pacify picky compilers.

autoconf is, and will be even more, a picky compiler.  If you can't
leave with its complains, fix them!  If you can, ignore them.
Actually, if that's so much of a trouble for you, I'll be happy to
make them a warning set by default.  Then with

WARNING=no-token-control

in your env, you'll never hear about it again.  But by default, these
sanity checks *must* be kept.



reply via email to

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