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: Bernard Dautrevaux
Subject: RE: 10-forbidden-tokens-in-comments.patch
Date: Thu, 18 Jan 2001 16:59:04 +0100

> -----Original Message-----
> From: Akim Demaille [mailto:address@hidden
> Sent: Thursday, January 18, 2001 10:37 AM
> To: Bernard Dautrevaux
> Cc: APatche
> Subject: Re: 10-forbidden-tokens-in-comments.patch
> 
> 
> >>>>> "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.

The problem here is that AX_SOMETHING is not always a macro name and in fact
is NOT looking as any existing macro name :-)

> 
> 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.

I agree with autoconf being intolerant about what is probably an error, but
it should not consider everything as being a potential error.

> 
> 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.

OK, I surrender on this; I was just pushing an idea a bit too far :-)

> 
> 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.

I think the problem is not releasing AF and AI; either we claim EVERYTHING,
or we claim only the used prefixes, giving a way to autopackage to claim the
AP_ name space.

> 
> 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.

I'm afraid I don't agree with that; having to tweak configure.ins and create
some, I've found quite useful to add '#' comments with macro calls in them,
so that in the resulting configure script I can know which line in
configure.in is creating a problem. It help me a lot finding under-quotation
problems for example, that give VERY strange errors (like 'unexpected EOF'
signalled on the last line of the script).

> 
> 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.
> 

The difference is that C do not force you to write "/* nothing */;" instead
of a plain ";". You just add it for the user to be happy and to understand
what's happenning. The fallthru example is a hack IMNSHO for compilers (and
usually for LINT) that were SO picky that it was not possible to write a
program that has no warnings but nevertheless makes some non-trivial work.

> 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.
> 

Agreed; I always favor as picky as possible sanity checks, but not more
picky than reasonable. You know in C as soon as you declare an extern
variable, you MAY create a new, difficult to find, bug. But if a compiler
warned for ANY extern thing, I would HAVE to turn warnings off (especially
if I cannot turn only this warning off).

At first I think I would favor your third option, but I then thought the
second is better: when I run autoconf manually, I will get the picky
warnings; when I start it from my automated scripts, I will add the proper
'not-too-picky' option and will have a clean log to check for unexpected
warnings or errors.

Regards,

        Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:    +33 (0) 1 47 68 80 80
Fax:    +33 (0) 1 47 88 97 85
e-mail: address@hidden
                address@hidden
-------------------------------------------- 



reply via email to

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