Re: Autotools lint tool

[Warren Young]

On Oct 2, 2019, at 9:58 PM, Gabriel Lisaca <address@hidden> 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).

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.

> There is also the case of practices that I have found online that seems--at 
> least on the surface--that is what most autotools projects do nowadays. These 
> are things like AC_CONFIG_AUX_DIR([build-aux]) and AC_CONFIG_MACRO_DIR([m4]).

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

Again, if you find a case where the Autotools aren’t warning you that you 
should be doing something you aren’t, post it, and we’ll consider adding a 
diagnostic for it.

> stuff like M4 quoting that, due to the rather foreign nature of the M4 macro 
> language, confused me initially.

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.

> the "lint" tool I was referring to would be similar to shellcheck [1] where 
> it doesn't “Emulate the build environment for every OS you need this project 
> to build on.” since it would not be practicable as you have said. Instead, it 
> checks for known non-portable and/or error-prone constructs, as well as more 
> idiomatic ways to do common things.

Tools like shellcheck have an easier job: they’ve got a single language to 
check, and they’re working from a formalized standard.  In our case, Autotools 
is as Autotools does, and changing it is often difficult, because that 
introduces new portability problems.

There’s also the fact that a tool like shellcheck has a much wider potential 
user base, so there’s going to be more available developer attention for such a 
thing.  There are probably orders of magnitude fewer Autotools users than POSIX 
shell script writers.

> Note: I'm very new to mailing lists. Is this how I'm supposed to reply?

On some mailing lists, a simple reply does go to the mailing list address, but 
there’s an intractable philosophical argument over whether that’s the right 
behavior:

   https://mail-list.com/reply_in_a_mailing_list/

This list happens to be the sort where simple replies go to the poster only, so 
you’d need to do a Reply All then optionally trim the addresses appropriately.

> I don't know which email I should CC (if any) to make sure it goes back on 
> the public list.

address@hidden