wgetpaste icon indicating copy to clipboard operation
wgetpaste copied to clipboard

Add meson.build script

Open nvinson opened this issue 9 months ago • 8 comments

Closes: issue #58

nvinson avatar Feb 28 '25 05:02 nvinson

I think using a Makefile would be a better idea because make(1) is more portable. I have created a pull request that works with POSIX make.

unrealapex avatar Feb 28 '25 10:02 unrealapex

I'm not sure the difference between meson and make is really valuable here in terms of portability. But the Makefile PR doesn't support tests, nor does it respect DESTDIR.

thesamesam avatar Feb 28 '25 11:02 thesamesam

+1 for using meson, by now it's available on about every platform since many popular packages require it. It's also a fair bit more maintainable IMHO.

Cogitri avatar Feb 28 '25 11:02 Cogitri

I think using a Makefile would be a better idea because make(1) is more portable. I have created a pull request that works with POSIX make.

You claim that it's more portable but I count 3 distinctive errors in your Makefile that make it not even work on the most boring and common platform of all -- Debian Linux amd64. The meson.build solves all 3 errors (two of them intrinsically by meson itself, and one of them by the specific implementation of meson.build).

eli-schwartz avatar Mar 02 '25 20:03 eli-schwartz

I mean to say that make(1) is available on on more systems. I would appreciate it if you could make a comment on #60 with improvements to make.

unrealapex avatar Mar 03 '25 01:03 unrealapex

But the Makefile PR doesn't support tests, nor does it respect DESTDIR.

I will fix this. Thanks!

unrealapex avatar Mar 03 '25 01:03 unrealapex

I mean to say that make(1) is available on on more systems. I would appreciate it if you could make a comment on #60 with improvements to make.

I don't think it's worth investing time and energy into a sinking ship.

Make isn't a build system, it's a low-level dependency graph actualizer. I've seen thousands of people claim that "it's so simple to write a simple POSIX makefile" and I can count on the fingers of one hand, the number of people who were able to do it correctly. Using a real build system such as autotools or meson allows you to avoid making those mistakes in the first place.

I hate to say it but the existing criticism to which you replied

I will fix this. Thanks!

is nickle-and-diming. The fact that you didn't even get the first and most fundamental part of writing a "simple Makefile" correct doesn't fill me with confidence that you're approaching this from the correct attitude of writing a build system, and I don't want to spend all my time explaining repeatedly why things are important and "it's not that simple" when you end up using Makefiles as a dependency graph actualizer loosely untethered to things such as standards.

Maintaining a raw Makefile requires actually understanding these nuances. Contributing one, even if it was correct in the first place, doesn't mean it will be maintained properly in the future (raw Makefiles rarely are) and especially doesn't mean other people will maintain it correctly.

If you're adamant that what the world really needs is more build systems that run on SCO OpenServer, IRIX, SunOS (pre Solaris), and Tru64 with "just POSIX utilities and Make" then please, do everyone a favor and utilize autotools.

If you just want it to run on Alpine Linux without having to apk add any additional packages then please understand that this motivation is entirely backwards.

...

Even if I assumed the Makefile was actually correct, it's actually undesirably painful by sheer virtue of it being a Makefile. Linux distros can automatically package any software that utilizes a script called ./configure, makefiles require inconsistent custom handling in every single case including manual investigation of which among about 50 different override variable styles any given package respects, and whether or not it respects environment variables. A Gentoo ebuild has to be much longer just because you use Makefile without ./configure. And meson solves the same problems ./configure solves.

eli-schwartz avatar Mar 03 '25 02:03 eli-schwartz

Thank you for the informative comment and bestowing me with your knowledge of build systems! I think using this PR would be a better approach. I hadn't understood the purpose of autotools until you mentioned it. I will take this as an opportunity learn more about how to use it in projects.

unrealapex avatar Mar 04 '25 01:03 unrealapex

@Cogitri Hello, are there plans to merge this PR?

nvinson avatar Sep 11 '25 00:09 nvinson