On Thu, 30 Dec 2021 23:07:35 +0100
Laslo Hunhold <dev_AT_frign.de> wrote:
> On Thu, 30 Dec 2021 21:17:32 +0100
> Mattias Andrée <maandree_AT_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 "$(_AT_:.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
Received on Fri Dec 31 2021 - 00:08:33 CET