Useless use of GNU by Julio Merino

[YYY__]

After trying to install a NetBSD system for fun, spoiler: Intel 3945ABG support isn't polished, I dug around the web to feed my optimism towards the Unix way and found this interesting article by jmmv about portability and dead ends from GNU.

Useless use of GNU - Julio Merino (jmmv.dev)

The GNU project is the source of the Unix userland utilities used on most Linux distributions. Its compatibility with standards and other Unix systems, or lack thereof, directly impacts the overall portability of any piece of software developed from GNU/Linux installations. Unfortunately, the...

jmmv.dev

 

[zirias@]

To me, that's all well-known stuff, but it's good to actually spread that knowledge.

The part about make is slightly "weak", but that's already acknowledged in the text with the correct reason given:

Relying on GNU Make is a fine thing to do given that the minimum common denominator for Makefiles is extremely limited feature-wise

That's why my own home-grown "make library" for building C and C++ projects relies on GNU Make. It could use BSD Make as well I guess, but GNU Make is just more widespread and available virtually anywhere. "Portable Make" definitely wouldn't fit the bill, unfortunately...

Fun fact: the only really portable solution to that "make dilemma" that doesn't force additional dependencies on the user who just wants to build something is a GNU project: GNU autotools. The neat trick here is a (generated) bourne shell script (POSIX-compliant) that's distributed with the source and itself generates portable Makefiles. Unfortunately, GNU autotools are a damn PITA to use, at least IMO.

 

[kpedersen]

The neat trick here is a (generated) bourne shell script (POSIX-compliant) that's distributed with the source and itself generates portable Makefiles.

The complexity of this script always makes me shudder. For example in a complex project like gcc itself, I can't imagine a ./configure script still working on a POSIX-like system 50 years from now.

But then again, CMake *feels* clean. But there is no guarantee that will stand the test of time any better than autotools (and Meson / Bazel are just gimmicks). Personally if I really had to choose, I would go for an awk script to build up some Makefiles (adhering to the lowest common denominator).

It is frustrating because I still have a little bit of trauma trying to wrangle the ancient Xorg xmake in the original CDE source drop. Build systems suck!

 

[zirias@]

I can't imagine a ./configure script still working on a POSIX-like system 50 years from now.

I wouldn't have any doubts about THAT, as long as there's no custom shell code in the configure.ac file. What's generated by autoconf is POSIX-compliant and portable

But then again, CMake *feels* clean.

BUT: It's an additional build dependency So far, I opt for GNU Make instead (which is a really capable Make tool, although the docs aren't the best). At least on SOME systems, it's always available (Linux, Windows/MSYS2, ...)

 

[kpedersen]

I wouldn't have any doubts about THAT, as long as there's no custom shell code in the configure.ac file. What's generated by autoconf is POSIX-compliant and portable

True but it probably does i.e some string munging of `uname` or something lower down. There is no guarantee that a uname of the future will be in a "sane" format. FreeBSD today might be "++Quantum- <space> <space> ix the 3rd" or something weird. So you would end up needing to generate a new updated ./configure script from a "modern" autotools if it is still around that understands the weird uname.

BUT: It's an additional build dependency So far, I opt for GNU Make instead (which is a really capable Make tool, although the docs aren't the best). At least on SOME systems, it's always available (Linux, Windows/MSYS2, ...)

Yes, very true. Potentially bmake (from the pkgsrc) is very easy to build on Windows (and others) but yes, unlike gmake it isn't there free on Linux-y platforms.

 

[zirias@]

True but it probably does i.e some string munging of `uname` or something lower down. There is no guarantee that a uname of the future will be in a "sane" format. FreeBSD today might be "++Quantum- <space> <space> ix the 3rd" or something weird. So you would end up needing to generate a new updated ./configure script from a "modern" autotools if it is still around that understands the weird uname.

I don't see a reason why the generated parts should do something like that, but sure, there's no guarantee it's all perfectly standard bourne shell stuff. Still, I'd argue GNU autotools is the one thing that's closest to a "perfectly" portable build-system without extra dependencies. I just mentioned it on this thread to give an example how GNU actually cares about portability. There are some bad choices of course (as highlighted in the blog post), but the major problem is the predominance and people not even thinking about what is portable and what isn't...

I just don't use autotools cause I hate M4 ? (seriously, it's quickly getting out of hands...)

Yes, very true. Potentially bmake (from the pkgsrc) is very easy to build on Windows (and others) but yes, unlike gmake it isn't there free on Linux-y platforms.

Yes, probably. And about BSD Make, I like how there is a single well-structured man-page that documents everything you need to know. But then, if you decide to build with hand-written Makefiles only, you pick the implementation that's more widespread....

 

[covacat]

for bsd make
/usr/src/contrib/bmake/PSD.doc/tutorial.ms
use groff -ms to read/convert it