Martin D Kealey <mar...@kurahaupo.gen.nz> writes: > > At this point I'm beginning to question the value of autoconf for "general > use". I'm sure it's still useful for corner cases, but it was conceived for > a different world, and assumptions made back then have become problems now. > > And it's SLOW. On my fairly old computer, autoconf is a major choke point > for builds: it takes around 20 seconds, while the entirety of the rest of > the build takes about 22 seconds. On newer systems (with more cores) it > probably *exceeds* the time taken by the rest of the build. Are there any > plans to improve autoconf? Or replace it? Perhaps we could have a > supplementary config system that assumes full C99/07/11/17/23 and POSIX > compliance, and just allows tweaking compiler options and build paths?
If one was writing software for only Linux with glibc, then maybe autoconf (or meson, cmake, etc.) would not be necessary. But for software that is intended for many operating systems (Hurd, AIX, *BSD, Solaris, etc.), as most GNU software is, it makes life much easier. For example, all the listed platforms hide platform extensions/standards behind different macros. And each platform has bugs in it's implementation of the standard. Regarding your specific issue, I would recommend modifying your wrapper to remove -Werror when running the configure step. In Gnulib [1], our m4 files attempt to avoid any possible warnings. So, for example, we will use any variables we declare, and make sure functions are declared before they are used. However, it is sometimes not possible to avoid them all. Also, I would avoid -pedantic as well. Most GNU software will use GNU C extensions that, in practice, are portable enough. Collin [1] https://www.gnu.org/software/gnulib/
