> solved problem

autotools is horrifying. I'm not claiming that there is an obviously better way to solve the problem that it tries to solve, but it is horrifying.

FTR, I have much more experience with cmake, which is also horrifying. (Maybe there is no non-horrifying way to solve this problem?)

▲

badsectoracula an hour ago | parent [-]

GP most likely meant it was a solved problem from the user's perspective. Autotools might be "horrifying" for the programmer (IMO that is an exaggeration, AT isn't that bad, with the potential exception of libtool) but it provides by far the best UX for a user (that knows how to use a command line and what building from code is, not your average grandma :-P) compared to everything else out there.

However one important aspect here is that there is no reason for Autotools to be what provides the `./configure && make && make install` UX - the GNU standards (not sure the exact name) describe the UX itself without mentioning anything about Autotools so any other approach to implementing it would be just as valid. However in practice whenever you find a configure script in the wild it is either Autotools or a hand-made one (that more often that not misses some of the GNU standard stuff).

	▲	rbanffy an hour ago \| parent [-]
		Autotools can be daunting if you plan to write code that’s portable to Ultrix, IRIX, Apollo’s UNIX whose name I forgot, NonStop, UNICOS, OpenVMS, z/OS, macOS, and modern Linux. Nowadays we don’t bother supporting dozens of platforms. Even Windows is something we can push aside and suggest WSL if you really need to run it under Windows. And I even try to make sure my code runs correctly on z/OS (which IS a UNIX).