Re: Autotools lint tool

[Warren Young]

On Oct 2, 2019, at 7:05 PM, Gabriel Lisaca <address@hidden> wrote:
> 
> wondering if there are any lint tools available for checking the 
> "correctness" of a project's configure.ac file as well as its Makefile.am file

I don’t think it’s a practical possibility, since it would amount to “Emulate 
the build environment for every OS you need this project to build on.”  It’s 
literally less work to just set up a set of VMs, one for each major OS you need 
your project to build on.

Yes, it would be nice if someone else could do that VM work setup for you and 
then script the trial and analysis steps up for you so that you get out a short 
list of warnings and errors, but that also doesn’t seem like a practical 
possibility.

Your question is based on a weak premise: that “lint” is a good match for what 
goes on in the Autotools.  The first lint tool was written for C, a language so 
simple that it could be implemented on an early PDP-11, which means it ran in 
at most 64k of RAM.

What happens in the Autotools is that you’re testing the output of whole 
systems of components, many of which are too big to run on a PDP-11.  Just take 
“echo” portability testing: that means you need to check /bin/echo, the 
built-in echo of the shell you’re running, and maybe that of a shell you have 
on the system but which is potentially more portable and thus which Autoconf 
will switch to automatically.  One or more of those shells is likely many times 
bigger than would run on a PDP-11 alone.

And that’s just one feature.

There’s a good reason why an Autoconf configure script runs so slow, even here 
in 2019: it’s doing a *lot* of work.  What you’re proposing is to abstract all 
of that work to a higher level set of rules that covers behavior across all 
OSes you need to support.

Ironically, what it would take to break this logjam would also obviate the need 
for Autotools in the first place: a standard build environment, specified as 
tightly as the rules for the early C compilers, so that a concise set of rules 
and tests can be constructed that checks for compliance.  If we had that, we 
would indeed have nothing left but “lint” after you got your build system 
running on one system, because the differences with respect to all the others 
would be tiny.

That’s not reality, though we are approaching it slowly.  “Real” Unix is all 
but dead now, the Linuxes are converging on a few major types, and the 
fragmentation in the BSDs seems to have reached a practical limit.  
Alternatives like macOS and Windows WSL hew to one of the above standards.  The 
OS compatibility problems we have these days are nowhere near as bad as those 
in which the Autotools were created.

The closest you’re ever likely to get to Lint for Autotools is better warnings. 
 And for that, your best bet at a fix is to report a case where you coded 
something wrong and the relevant Autotool didn’t catch the bug for you.  
Someone may then decide to add code to check for the problem.  There’s a lot of 
such code in the Autotools already.