Add meson.build script

[nvinson]

Closes: issue #58

[unrealapex]

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.

[thesamesam]

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.

[Cogitri]

+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.

[eli-schwartz]

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).

[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.

[unrealapex]

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

I will fix this. Thanks!

[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.

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.

[unrealapex]

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.

[nvinson]

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

[Cogitri]

Oh my god, I forgot to actually submit the review comments I made 7 months ago, sorry! Please take a look at them now that I actually published them :)

[Cogitri]

I'm probably just ignorant, but do we really have to make the shebang configurable? Isn't /usr/bin/env supposed to be universal?

[nvinson]

I'm probably just ignorant, but do we really have to make the shebang configurable? Isn't /usr/bin/env supposed to be universal?

The configuration is optional. If the builder does not set WGETPASTE_SHEBANG it defaults to /usr/bin/env bash.

/usr/bin/env does depend on the environment variable PATH being correctly set to find bash. Generally this isn't a problem, but on the few occasions it is, this option allows a downstream builder to hard code the correct path for bash.

[eli-schwartz]

If a bash script happens to use features of Bash 4.x then using /usr/bin/env bash is unreliable and will break on systems such as macOS where you must guarantee that the "correct, new enough* version of bash is utilized regardless of how the user configures $PATH.