On Wed, Jun 19, 2024 at 08:44:14AM -0600, Warner Losh
wrote:
On Wed, Jun 19, 2024, 7:28???AM Larry McVoy
<lm(a)mcvoy.com> wrote:
> On Tue, Jun 18, 2024 at 07:46:15PM -0500, Nevin Liber wrote:
> > But I'll bite. There was the claim by Larry McVoy that "Writing
> Makefiles
> > isn't that hard".
>
> > Please show these beautiful makefiles
for a non-toy non-trivial
product
> Works on *BSD, MacOS, Windows, Linux on a bunch of different
architectures,
Solaris,
HPUX, AIX, IRIX, Tru64, etc.
The posted Makefile is no a strictly conforming POSIX Makefile, but uses
gmake extensions extensively... And eyes of the beholder may vary...
Yeah, I lost that battle. I prefer, and carry around the sources to, a
make from Unix. It's simple and does what I need. But my guys convinced
me there was enough value in gmake that we used it. I tried to keep
the craziness to a minimum. And I think I succeeded, I can fix bugs in
that Makefile.
I thought the ask was for a POSIX one that did that, hence my comment. I
agree that is a fools errand for anything non-trivial.
I can do way better using BSD's make since i can hide almost all the
ugliness behind the scenes... Though what's hidden has rightfully been
criticized already (I did diagree with some of it, but the main points
still stand with my quibbles so I let it go).
In many ways I really like cmake's declarative approach. I like bmake's
include macros that try to do similar, but more constrained, things. I like
that cmake figures things out, though I've done too much battle to control
how it does things, but I digress.
It's useful to have a tool that can do dependencies. However, you need a
higher level tool to generate input to that tool, like meson with ninjamake
or cmake. Combining them like gmake or bmake creates a nice macro assembler
that can be made to work, but the pain winds up being in all the wrong
places and the needs to constantly refactor is high to try to retain the
simplicity.
Warner