[prev in list] [next in list] [prev in thread] [next in thread] 

List:       autoconf
Subject:    Re: Autotools lint tool
From:       "David A. Wheeler" <dwheeler () dwheeler ! com>
Date:       2019-10-04 2:09:45
Message-ID: E1iGD2P-0002OR-SP () rmmprod07 ! runbox
[Download RAW message or body]

> On Oct 2, 2019, at 9:58 PM, Gabriel Lisaca <gabriel.lisaca@gmail.com> wrote:
> > Sorry, I may have made my question unclear. What I meant by a "lint" tool for \
> > autoconf (and the autotools in general) is to check rather trivial things like \
> > syntax and arguments to macros to conform to what the documentation intends \
> > (e.g., number of arguments to a macro).

On Wed, 2 Oct 2019 23:05:25 -0600, Warren Young <warren@etr-usa.com> wrote:
> That's the "better diagnostics" case I brought up in my reply.  Give us a case \
> where one of the Autotools didn't detect incorrect syntax, and someone will likely \
> add a check for that case or explain why a check can't be written.

Typical "linters" usually don't look for *incorrect* syntax, since other tools \
already do that, and instead work to identify constructs that are likely wrong (even \
though they are syntactically correct).

That said, I completely agree that it'd be very wise to *first* create a list of some \
checks you'd like to implement, and then find the best way to implement them. Then \
you'll know what the linter will need to do. Also, although autoconf and automake are \
separate tools, they are often used together, and a linter needs to be prepared for \
that combination.

Here are some potential ideas of rules an autotools linter might check:
* Warn about non-empty macro arguments that are non-numbers and aren't surrounded by \
[...]. These are syntactically legal, but can lead to trouble, so my simple rule is \
                to always surround non-numbers with [...].
* Warn about whitespace between a macro name and its following invoking '(".
* Warn about whitespace following an argument (after "," or before the closing ")").
* Require including this line: AC_CONFIG_AUX_DIR([build-aux])
* Require including this line: AC_CONFIG_MACRO_DIR([m4])
* If there's a "Makefile.am", require that it include ACLOCAL_AMFLAGS = -I m4 \
                --install
* If there's a "Makefile.am", complain bitterly if it includes "SUBDIRS="; that \
suggests a recursive build, which is almost always a terrible idea that leads to \
endless trouble.

These are rules I follow and mention in https://www.youtube.com/watch?v=4q_inV9M_us

I would also consider this rule:
* Bitterly whine about any use of m4's changequote.  Yes, it's syntactically allowed, \
but that will totally confuse many people & tools.

I strongly urge you to implement some way to disable the next warning
from a comment *within* the code, so that if a warning is a false positive
it's still possible to end up with a clean result.
Most modern linters (like shellcheck) can do this.

> The Autotools do detect many such cases already.  For example, it'll yell at you if \
> you name the input to Autoconf "configure.in", its original name, replaced about 10 \
> years ago with "configure.ac".

Which is great!  In those cases it's probably not worth implementing the same check \
in your linter (unless, of course, you worry some people will only be using old \
versions of autoconf).  Conversely, if the check can be added to the autotools \
themselves, that might be worth doing.

> I'm not sure a macro language like M4 can be reliably syntax-checked, since it \
> intermixes two or more different languages.  The higher level (M4) doesn't know the \
> rules of the lower level language, and the lower-level language (shell, in this \
> case) can't see the higher level, being already pre-processed. 
> A "lint" tool for a given pairing could be written, but it'd need to understand \
> both languages' syntaxes and how they interact.  Tricky.

Not really. In many cases a linter needs only understand the m4 syntax, so that it \
can figure out where the arguments begin & end.  Instead of handling arbitrary \
lower-level syntax, it could simply check only certain arguments of certain macros to \
see if they meet certain rules.

A linter only needs to focus on detecting *common* mistakes and/or enforce a style.  \
Hopefully the style rules themselves exist to help avoid common mistakes.  As long as \
you only try to do that, the inability to handle everything is just fine.

--- David A. Wheeler
_______________________________________________
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf


[prev in list] [next in list] [prev in thread] [next in thread]