> I don't really see why anyone would pick autoconf for a modern project.
If you build for your system only and never ever plan to cross compile by all means go with static makefile.
Most of my disdain for Autoconf was formed when I worked at a company where I developed a embedded Linux distro from scratch. I cross-compiled everything. Most of the crap I had to fight with was Autoconf projects. I was having to do things like export various ac_cv_... internal variables that nobody should know about, and patching configure scripts themselves. Fast forward a few years and I see a QEMU everywhere for "cross" builds.
The rest of my disdain comes from having worked with the internals of various GNU programs. To bootstrap their build systems from a repository checkout (not a release tarball) you have to follow their specific instructions. Of course you must have the Autotools installed. But there are multiple versions, and they generate different code. For each program you have to have the right version that it wants. If you have to do a git bisect, older commits may need an older version of the Autotools. Bootstrap from the configure system from scratch, the result of which is the privilege to now run configure from scratch. It's simply insane.
You learn things like to touch certain files in a certain order to prevent a reconfigure that has about a 50% chance of working.
Let's not even going to libtool.
The main idea behind Autoconf is political. Autoconf based programs are deliberately intended to hinder those who are able to build a program on a non-GNU system and then want to make contributions while just staying on that system, not getting a whole GNU environment.
What I want is something different. I want a user to be able to use any platform where the program works to obtain a checkout if exactly what is in git, and be able to make a patch to the configuration stuff, test it and send upstream without installing anything that is not required for just building the program for use.
https://wiki.debian.org/CrossCompiling https://crossqa.debian.net/
Yeah well this is not quite true. Most embedded distros leverage autotools heavily. In Yocto you just specify autotools as the package class for the recipe and in most cases it will pull, cross compile and package the piece of software for you with no intervention.
The tools are clearly antiquated, written in a questionable taste and 80% of the cases they solve are no longer relevant. They are still very useful for the rest.
Sure, Autotools can do this and that ... given a significantly large and busy crew of downstream packagers who compensate for this and that in their distros.
It's a lame horse that needs to be buried.
The main thing that's wrong with Autotools perhaps is that it is shielded from fixes. Autotools makes a cockery of a project's configuration, and then downstreams concentrate on fixing the cockery to get that project working right. The fixes do not go back to Autotools!
There is already very little feedback between distros and upstream projects. Most of the time distros fix things silently, get things working and never contact upstream. (I've often learned of build issues in my projects by browsing downstream issues and discussions. They do not contact you! I would patch their problem. Then check a month later after a release and yup, "patch no longer applies; upstream fixed this; issue closed").
And now Autotools is one more hop behind upstream! Most people causing problems with Autotools will never be contacted, and those that are will never fix/improve or at least report anything in Autotools. If they do, they will probably just be told they are using Autotools wrong, go away.
Thus the Autotools project is blissfully oblivious to the idea that it might be a problem. Like an elephant in the room that is lying on your sofa, sipping a margarita and watching TV.
Are you sure? I was certain that if the package isn't necessary for build process it is built for target only. Some of the packages on our products are in fact impossible to build for the host which is a pretty good hint.
Cross compilation for distributions is a mess, but it is because of a wide proliferation of build systems, not because of the GNU autotools -- which have probably the most sane way of doing cross compilation out there. E.g., distribution have to figure out why ./configure is not supporting --host cause someone decided on writing their own thing ...
> The main idea behind Autoconf is political. Autoconf based programs are deliberately intended to hinder those who are able to build a program on a non-GNU system and then want to make contributions while just staying on that system, not getting a whole GNU environment.
Nothing could be further from the truth, GNU autoconf started as a bunch of shared ./configure scripts so that programs COULD build on non-GNU system. It is also why GNU autoconf and GNU automake go such far lengths in supporting cross compilation to the point where you can build a compiler that targets one system, runs on another, and was build on a third (Canadian cross compile).
1. Most of the time ./configure won't properly support --host isn't because someone wrote their own thing, but because it's Autoconf.
2. --host is only for compilers and compiler-like tools, or programs which build their own compiler or code generation tools for their own build purposes, which have to run on the build machine rather than the target (or in some cases both). Most programs don't need any indications related to cross compiling because their build systems only build for the target. If a program that needs to build for the build machine has its own conventions for specifying the build machine and target machine toolchains, and those conventions work, that is laudable. Deviating from the conventions dictated by a pile of crap that we should stop using isn't the same thing as "does not work".
If you need to compile programs that run on the build machine, you should have a ./configure script which allows a host CC and target CC to be specified, and use them accordingly. Even if you deviate a bit from what others are doing, if it is clearly documented and working, the downstream package maintainer can handle it.