That script is 2500 lines long, and appears to have been written by a wizard. If my only other option was producing something like that, I'd just bite the bullet and use autotools. (IDK, that may be your point?)

Do you honestly think that I gradually developed a 2500 line configure script by hand over more than six years for an important project of mine ironically, in order to promote Autocrap?

The script detects just what is necessary for the program and is easy for me to understand, extend, port and debug.

You can fix it right on a given target platform where you're trying to get it working.

You can't do that with an Autoconf configure script (in a way that you can merge back to your stream), because it's generated. You need an installation of Autoconf.

If you want to patch the Autoconf-generated configure script with minimal changes, just reflecting the topic of the change you're making, you need the exact same version of Autoconf with which it was generated, otherwise there will be irrelevant diffs all over the script.

(I learned this when I developed an embedded, cross-compiled LInux distro from scratch. On my development system, I had about half a dozen installations of different versions of Autoconf, so that I could create minimal patches against configure scripts!!!)

And, of course, you first have to work backwards to figure out how to coax the script behavior you want indirectly through the m4 macro files. Forget about "I just want to make this tiny tweak in one command and it will Just Work".

In my script, you just ... open the script and write the necessary code. Then regression-test it on the other targets, do any necessary tweaking and commit.

Once you have written one of these scripts, you can easily re-use it. My above script is BSD-licensed. Anyone can take it and cut out whatever they don't need. If you want help using it or have any questions, you can fire me an e-mail.

Thanks!