Re: [dev] Make cleanup

From: Laslo Hunhold <>
Date: Sun, 30 Dec 2018 10:35:38 +0100

On Sat, 29 Dec 2018 20:32:13 -0500
stephen Turner <> wrote:

Dear Stephen,

> If one was going to rewrite a cleaner make what would be the
> recommended approach?
> I see in a slightly older 2012 release of the code entries for
> windows 32 and amiga. I’m questioning why!
> Would it be worth while to strip make of these items and then attempt
> to clean the code section by section? Diff a legacy and perhaps gnu
> exclusive version against a newer release, or perhaps another
> approach?

start fresh. GNU code tends to be spaghetti with lots of macros and
unnecessary stuff. It's so bad that even for POSIX-programs which I
could implement myself easily I have a hard time understanding
sometimes what the GNU version of it does.

> In the past I have learned coding by jumping into an existing item
> and rewriting, not sure if this is a task I will take on but the
> thought has crossed my mind.
> I am not skilled enough to start from scratch and make is just too
> bloated as is to try and tackle for me, I’m thinking perhaps removing
> these legacy items and going from there?

Really helpful would be a make-implementation that is 100% POSIX[0]. It
makes me sad to see that most Makefiles use GNU-extensions, as they are
not necessary in most cases and make them unportable.

As it is with many other things (bash, coreutils, ...) the GNU project
does not care about portability and designs their tools to become
de-facto monopolies with "silent" dependencies on them (e.g. cat -v or
In the case of make, the BSD-implementations have their own share of
extensions and are not helpful to really write portable makefiles.
I'm not saying that the extensions are bad per sé and you could even
implement them in your make-version, but under the condition that you
print a warning when it is used (and maybe error out in some strict mode
or something).

Make is not magic, as Markus already elaborated well. Try to go the
path with the dependency graph, as it is probably the best way to
approach make using this formal method. On top of that though, keep it
simple! :D

With best regards



Laslo Hunhold <>

Received on Sun Dec 30 2018 - 10:35:38 CET

This archive was generated by hypermail 2.3.0 : Sun Dec 30 2018 - 10:36:08 CET