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

List:       autoconf
Subject:    Re: Autotools lint tool
From:       Warren Young <warren () etr-usa ! com>
Date:       2019-10-03 5:05:25
Message-ID: 155DCF5D-C954-4F41-8694-716476CDB732 () etr-usa ! com
[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).

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.

autoconf@gnu.org
_______________________________________________
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]