6 ms·

You can pre-answer most autoconf sections using /etc/config.site, and a system distributor can create an /usr/share/config.site[1]. It's just really hard to get

You can pre-answer most autoconf sections using /etc/config.site, and a system distributor can create an /usr/share/config.site[1]. It's just really hard to get right, nobody uses it effectively. Autoconf also has a config.cache[2], which it uses to store answers to reuse across multiple of the same checks and reruns of the configure script. [1]: https://www.gnu.org/software/autoconf/manual/autoconf-2.63/html_node/Site-Defaults.html https://www.gnu.org/software/autoconf/manual/autoconf-2.63/h... [2]: https://www.gnu.org/software/autoconf/manual/autoconf-2.65/html_node/Cache-Files.html https://www.gnu.org/software/autoconf/manual/autoconf-2.65/h...

mdaniel 3y ago
and if I understand correctly, any such /etc/config.site falls prey to one of the more famous N problems in computer science, since the only truly stable things one could put in any such file would be the host triple and byte order. Maybe if there was a systemwide hook into deb or rpm to regenerate it after any package updates it would solve the cache invalidation part
- bandrami 3y ago
  pkg-config was supposed to solve that, but, well, you know...
fanf2 3y ago
In my experience, config.cache fails to properly separate platform feature tests from build configuration options, so you need to delete config.cache if any build options change. It is extremely brittle and buggy. config.cache is definitely not suitable as a basis for for platforms to provide pre-cooked answers to platform feature tests.
- professoretc 3y ago
  In other words, it's not just as simple as "figure out how to compile things on this system, once, and then reuse that information in the future". Different projects can be compiled with different options, cross-compilation is a thing, etc. As soon as you try to solve this with a simple global `site_config.h` you discover that that doesn't quite work.
jonstewart 3y ago
I use autotools for my C++ projects and I hate it (in my weak defense, I hate cmake more). config.cache helps (and ccache helps a lot, too; most of my ccache hits are on stupid autoconf test programs; ya gotta use ccache if you use autoconf), but rerunning configure is still s l o w. Worse, automake and autoconf have a cyclic dependency, so if you're a developer (as opposed to a user building from source on a system) you wind up running configure all the time. This is because, most probably, your Makefile.am lists every source file individually. If you add a new source file, you must rerun autoreconf to regenerate your Makefile — and that also generates configure anew. Then the Makefile sees that configure is newer than config.h (or some other output, I don't want to look up the gory details) and, blammo!, when you run make, first configure runs. Of course with git, this happens not just when you add a new source file to your project... it happens whenever you switch branches, where there's variance in the source files in the project. configure configure configure configure. As much as I hate it, autoconf isn't the worst part of autotools. Automake is... pointless? Is it really less effort to write Makefile.am than to write a straight Makefile? Wouldn't that be simpler? And then there's libtool, which should be drug out into a back alley and executed. A 2000 LoC shell script, whose whole purpose in life is to figure out, over and over and over again, stateless in the same way as TFA complains about with autoconf, precisely which compiler flags should be used to build a shared library on a system amongst all the old compilers, even though today everyone just uses gcc and clang, which are flag-compatible, and determining which flags to use is not really that hard. Please, someone, anyone, please kill libtool and banish it from this earth. I tried Meson — ran into a problem, read the docs, asked a question on the mailing list, never got an answer, never got past it. Bazel's obviously a terrible Google project and won't work if you're not sufficiently Googly. Cmake, a disaster. I liked tup, but it seems to have died (and it didn't solve the autoconf problem anyway). Which new build system will deliver us from the 18th circle of hell? (probably cargo, as the Rust fanbois work to get C/C++ deprecated...)
- thechao 3y ago
  I'm be written lots of C code that runs on lots of architectures & platforms: PDPs, x86, ARM; Windows, BSD, Linux, VMS. My projects have spanned them gamut from tiny to gargantuan (millions of lines of code). I've never needed autoconf... what's it even for!?
NavinF 3y ago
> It's just really hard to get right, nobody uses it effectively Autoconf in a nutshell
jmmv 3y ago
Here is a more hands on article that I wrote about this specific topic not too long ago: https://jmmv.dev/2022/06/autoconf-caching.html https://jmmv.dev/2022/06/autoconf-caching.html

mdaniel 3y ago

and if I understand correctly, any such /etc/config.site falls prey to one of the more famous N problems in computer science, since the only truly stable things one could put in any such file would be the host triple and byte order. Maybe if there was a systemwide hook into deb or rpm to regenerate it after any package updates it would solve the cache invalidation part

bandrami 3y ago
pkg-config was supposed to solve that, but, well, you know...

fanf2 3y ago

In my experience, config.cache fails to properly separate platform feature tests from build configuration options, so you need to delete config.cache if any build options change. It is extremely brittle and buggy. config.cache is definitely not suitable as a basis for for platforms to provide pre-cooked answers to platform feature tests.

professoretc 3y ago
In other words, it's not just as simple as "figure out how to compile things on this system, once, and then reuse that information in the future". Different projects can be compiled with different options, cross-compilation is a thing, etc. As soon as you try to solve this with a simple global `site_config.h` you discover that that doesn't quite work.

jonstewart 3y ago

I use autotools for my C++ projects and I hate it (in my weak defense, I hate cmake more). config.cache helps (and ccache helps a lot, too; most of my ccache hits are on stupid autoconf test programs; ya gotta use ccache if you use autoconf), but rerunning configure is still s l o w. Worse, automake and autoconf have a cyclic dependency, so if you're a developer (as opposed to a user building from source on a system) you wind up running configure all the time. This is because, most probably, your Makefile.am lists every source file individually. If you add a new source file, you must rerun autoreconf to regenerate your Makefile — and that also generates configure anew. Then the Makefile sees that configure is newer than config.h (or some other output, I don't want to look up the gory details) and, blammo!, when you run make, first configure runs. Of course with git, this happens not just when you add a new source file to your project... it happens whenever you switch branches, where there's variance in the source files in the project. configure configure configure configure. As much as I hate it, autoconf isn't the worst part of autotools. Automake is... pointless? Is it really less effort to write Makefile.am than to write a straight Makefile? Wouldn't that be simpler? And then there's libtool, which should be drug out into a back alley and executed. A 2000 LoC shell script, whose whole purpose in life is to figure out, over and over and over again, stateless in the same way as TFA complains about with autoconf, precisely which compiler flags should be used to build a shared library on a system amongst all the old compilers, even though today everyone just uses gcc and clang, which are flag-compatible, and determining which flags to use is not really that hard. Please, someone, anyone, please kill libtool and banish it from this earth. I tried Meson — ran into a problem, read the docs, asked a question on the mailing list, never got an answer, never got past it. Bazel's obviously a terrible Google project and won't work if you're not sufficiently Googly. Cmake, a disaster. I liked tup, but it seems to have died (and it didn't solve the autoconf problem anyway). Which new build system will deliver us from the 18th circle of hell? (probably cargo, as the Rust fanbois work to get C/C++ deprecated...)

thechao 3y ago
I'm be written lots of C code that runs on lots of architectures & platforms: PDPs, x86, ARM; Windows, BSD, Linux, VMS. My projects have spanned them gamut from tiny to gargantuan (millions of lines of code). I've never needed autoconf... what's it even for!?

NavinF 3y ago

> It's just really hard to get right, nobody uses it effectively Autoconf in a nutshell

jmmv 3y ago

Here is a more hands on article that I wrote about this specific topic not too long ago: https://jmmv.dev/2022/06/autoconf-caching.html https://jmmv.dev/2022/06/autoconf-caching.html