On Oct 2, 2019, at 7:05 PM, Gabriel Lisaca <gabriel.lisaca@xxxxxxxxx> 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. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
