Rejuvenating Autoconf

Posted Nov 3, 2020 18:21 UTC (Tue) by anton (subscriber, #25547)
In reply to: Rejuvenating Autoconf by marcH
Parent article: Rejuvenating Autoconf

No thanks for palliative care of a project that has cost gazillions of developers a lot of their time and some of their sanity

Autoconf has saved me a lot of time. The alternative would have been to manually edit Makefile, config.h etc. for every platform we build on.

the problems solved by autotools have mostly disappeared

The problems are still there. If you don't want your project to be portable between platforms, nobody is forcing you to use autoconf. Gforth has portability as one of its goals, and thanks to autoconf previous releases have been portable to a wide range of OSs and CPU architectures, and we certainly want to stay portable (although admittedly we can no longer test on as many platforms as we used to).

I notice in many places, including your posting and the Meson design rationale a disdain for maintaining compatibility with old stuff. If everybody followed this principle, the software you use now would soon stop working; ok, so you get the new version (if there is one), but that would of course work differently than you are used to, so you have to change everything that you built that relies on it.

Interestingly, the first look at the Meson design rationale page gave the right impression; I had to adjust fonts and colours before I found it visually readable. Usually such pages are not worth reading, and that page was no exception.

Rejuvenating Autoconf

Posted Nov 3, 2020 20:09 UTC (Tue) by marcH (subscriber, #57642) [Link] (1 responses)

> I notice in many places, including your posting and the Meson design rationale a disdain for maintaining compatibility with old stuff.

I don't see any disdain at https://mesonbuild.com/Design-rationale.html#5-must-not-a... , just a trade-off because meson is not a well-funded, commercial project. Any other reference?

I love old stuff when bugs can be fixed cleanly where they are. My disdain is only for ugly workarounds - typically required by commercial and/or closed-source systems - unmaintenable wrapper and too many layers of indirection.

> Interestingly, the first look at the Meson design rationale page gave the right impression; I had to adjust fonts and colours before I found it visually readable. Usually such pages are not worth reading, and that page was no exception.

There seems to be fair number of projects who found meson documentation readable enough: https://news.ycombinator.com/item?id=24881897

The meson project is minimally "staffed" (which goes back to my initial comment) and last time I checked it was unsurprisingly not overstaffed with talented documentation experts. However it is very friendly to "drive-by" contributions so I bet they'll be delighted to accept fixes for your unusual browser configuration.

PS: I've met a surprising number of long-time open source hackers (even some famous ones) who have never used the "info" command. FWIW I do use it all the time.

Rejuvenating Autoconf

Posted Nov 4, 2020 11:53 UTC (Wed) by anton (subscriber, #25547) [Link]

Gforth is not a commercial project, either. That's why it supports portability beyond commercial considerations (e.g., 8 architectures were successfully tested on the latest release); by contrast, the most widely ported current commercial Forth implementation supports only IA-32, AMD64 (in development), ARM (32-bit) on mainstream OSs, and some embedded systems.

Considering Ubuntu 12.04 (the then-current LTS release) obsolete in December 2012 is a pretty strong sign of disdain for maintaining compatibility with old stuff, actually even with then-current stuff.

My "unusual browser configuration" is to heed the web page's requests for fonts and colours. The Meson developers invested a bit of their "minimal" staffing to ask for a tiny font and for light-gray-on-dark-gray colours. After working around that, the content is readable, but not worth reading.