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