6 ms·

Unfortunately, many FOSS projects, especially the successful ones, have a history of devs getting burned out and new ones coming along. Each new team has a set

Unfortunately, many FOSS projects, especially the successful ones, have a history of devs getting burned out and new ones coming along. Each new team has a set of favorite tools - even within the same language. They want to "clean up the mess" with a meta-build that replaces (or even worse, wraps) the legacy make system with a (supposedly) smarter, better system. This is how we end up with tools on top of make like configure, autoconf, cmake etc. If it's any consolation, the front end has gotten even worse. Try understanding a react project if you haven't internalized the architecture... typescript.tsx --> javascript.jsx --> javascript.js --> webpack --> minify --> god knows what. The irony is, js is an interpreted language! Didn't we (boomer coders) learn that interpreters act directly on code, and only compiled languages needed to be built? Forget about that. Aaand.. wait for it -- webgl, websockets, webasm! Our woes are just beginning.

cratermoon 4y ago
There's still nothing that beats imake for the X Window System. From Wikipedia: "imake generates makefiles from a template, a set of C preprocessor macro functions, and a per-directory input file called an Imakefile". And it does all this within the byzantine cathedral that is X.
jlokier 4y ago
> This is how we end up with tools on top of make like configure, autoconf In the case of configure and autoconf, it isn't. Those were created to solve a problem which a Makefile by itself wasn't able to do, which is portability to the plethora of unix systems and a few others. Nowadays a lot of software is not written with high portability in mind, and much of it is Linux only, but at the time Autoconf came out (1991) Linux barely existed, and there was no dominant unix-like OS. There were many different ones. Autoconf was quite refreshing as an end user. To make software portable so that people could build and run it on their systems, especially systems the software author didn't know about or couldn't test on. The consistent ability to run "./configure && make" and have it just work was a big improvement over the ad-hoc myriad ways of configuring downloaded software that were common at the time.

cratermoon 4y ago

There's still nothing that beats imake for the X Window System. From Wikipedia: "imake generates makefiles from a template, a set of C preprocessor macro functions, and a per-directory input file called an Imakefile". And it does all this within the byzantine cathedral that is X.

jlokier 4y ago

> This is how we end up with tools on top of make like configure, autoconf In the case of configure and autoconf, it isn't. Those were created to solve a problem which a Makefile by itself wasn't able to do, which is portability to the plethora of unix systems and a few others. Nowadays a lot of software is not written with high portability in mind, and much of it is Linux only, but at the time Autoconf came out (1991) Linux barely existed, and there was no dominant unix-like OS. There were many different ones. Autoconf was quite refreshing as an end user. To make software portable so that people could build and run it on their systems, especially systems the software author didn't know about or couldn't test on. The consistent ability to run "./configure && make" and have it just work was a big improvement over the ad-hoc myriad ways of configuring downloaded software that were common at the time.