On Thu, 30 Dec 2021 23:07:35 +0100 Laslo Hunhold <d...@frign.de> wrote:
> On Thu, 30 Dec 2021 21:17:32 +0100 > Mattias Andrée <maand...@kth.se> wrote: > > Dear Mattias, > > > I've actually being thinking of writing a makefile linter. > > How interested would people be in such a tool? > > very interested! Even though, when you implement the logic, you might > as well go all the way and offer a make(1) that also offers linting > (comparable to mandoc(1)). Yes, of course you could add it to make(1) also, but for the explained reasons I think it would be useful as a standalone implementation. However, a linter could do thinks that I do not want to do in make(1) itself. For example, it could do analysis to and find a portable solution (e.g. just removing "$(@:.o=.c)"), or explain that an non-standard feature is being used in vain (e.g. "PREFIX ?= /usr/local"). make(1) should of course tell you when you are not being POSIX compliant, but ultimately to what extent it would hold you hand and how pedantic it be would be determined at time of implementation. It would probably be very little. For example, I think that the linker could warn about bugs in other implementations or about potential whitespace issues which are probably just fine in every implementation people use, but I do not want to do this in make(1) itself. > > > The reason to have a linter separate from a make utility itself > > is that it would not have to reject non-standard features that > > you don't want to implement in make. And I also think it would for > > cleaner implementation of both projects. Additionally, I would > > suspect that a lot of people would just stay with GNU make because > > it's in every distro, so having it as a separate project would > > probably give it wider adoption. > > You wouldn't have to reject non-standard features, but offer printing a > warning for undefined behaviour and non-standard extensions while still > supporting them to a certain extent, something like: > > $ snake -l > Makefile:1:1: warning: Missing ".POSIX" target. > config.mk:2:4: warning: "?=" is a GNU-extension. > Makefile:20:34: warning: A prerequisite must not contain a macro. > $ > > Optionally you could also choose to always print warnings and turn > them into hard errors with the l-flag. > > It would be necessary to assess how many extensions are necessary > to implement. With sbase/ubase we found out that while GNU-extensions > are used, they are not all too widespread and only a small subset of > the entire GNU bloat. > > With Makefiles you don't really need the GNU extensions and they, > as usual with GNU extensions, seem to originate from a misunderstanding > or caving in to simply wrong usage-patterns (just think of cat -v) by > users who probably don't know it better or about the right tools for the > job. I think there are situations where some of the extensions offered by GNU are useful as they can make things cleaner, but they are hardly necessary, and often they are inappropriately used, and of course there are some features I cannot find an inappropriate use case for at all. GNU's strategy is to make things as easy for users as possible, and offer “more value” than the software they are replacing, which naturally lead to it's current miserable situation. They just haven't learned to say No. Which is probably to toughest but most valuable lesson for any programmer to learn. > > Anyway, tl;dr: Such a strict POSIX-compliant make would be really awesome! > I'm sure many would pick it up. Null program wrote a great post[0] > about this topic, indicating that there's no tool out there that is > explicit about standard conformance, _especially_ undefined behaviour. A few month ago I started writing a POSIX-like shell[0], it has requirements that makes it impossible to be fully POSIX, but it if you start it as sh it will be strictly POSIX and if it, in this mode, encounters an extension it will warn you that it will not be recognising it. It will also warn you in some situations that look like mistakes, and yell at you (in lower case) if you are using backquotes (read up on the backquote syntax in sh and you will understand why). > > With best regards > > Laslo > > [0]:https://nullprogram.com/blog/2017/08/20/ > Regards, Mattias Andrée [0] https://github.com/maandree/apsh
