5 ms·

Yeah, autoconf/autotools are a mishmash of old tools and scripts put together. I still can't get my head around what it actually does when you do ./configure (

Yeah, autoconf/autotools are a mishmash of old tools and scripts put together. I still can't get my head around what it actually does when you do ./configure (probably conjure some 70's Unix daemon to make sure your machine is not some crazy variant with 25-bit addresses) and I tend to avoid it whenever possible

citrin_ru 6y ago
1. It is relatively easy to see what exactly configure is doing - it is logged to config.log and you can edit configure and add an echo or change something to troubleshoot failure. Troubleshooting cmake failures is much harder in my experience. 2. In many cases it is possible to reduce number of checks configure is doing: configure.ac files often contain unnecessary stuff, probably copied from some other project and kept just in case.
- raverbashing 6y ago
  Oh I know what it is testing for, I just don't think a modern project needs to "checking for special C compiler options needed for large files" or check for the fsync command
  - citrin_ru 6y ago
    Most of such check are performed because a software author put some macro into autoconf.ac, sometimes without good reason or without any thought at all. I see this such attitude in many different areas e. g. people copy-paste some config options into software configs from some outdated how-to or StackOverflow and OK with now knowing what a given option does and if it is relevant in given case. May be with autotools it happens more often than with cmake (though I've seen enough bad CMakeLists.txt too) because there is a myth that autotools is very hard to learn so developer don't even try to read documentation and just put some random stuff into their .ac/.am files until it works for them albeit slow.
    - account42 6y ago
      If the configure tests were part of the dependency graph for parallel exection then any unneeded checks would simply not be run because nothing depends on them.
drewg123 6y ago
It was born in an era when there were many different *nix versions, all slightly different, with different names for include files, different C compilers with different flags, etc. Different OSes took differing numbers of arguments to certain library functions, etc. It was a necessary evil in the 90s. I still remember the perl config script that would say "Congratulations. You aren't running Eunice!" (Eunice was a bsd unix compat layer for VMS)

citrin_ru 6y ago

1. It is relatively easy to see what exactly configure is doing - it is logged to config.log and you can edit configure and add an echo or change something to troubleshoot failure. Troubleshooting cmake failures is much harder in my experience. 2. In many cases it is possible to reduce number of checks configure is doing: configure.ac files often contain unnecessary stuff, probably copied from some other project and kept just in case.

raverbashing 6y ago
Oh I know what it is testing for, I just don't think a modern project needs to "checking for special C compiler options needed for large files" or check for the fsync command
- citrin_ru 6y ago
  Most of such check are performed because a software author put some macro into autoconf.ac, sometimes without good reason or without any thought at all. I see this such attitude in many different areas e. g. people copy-paste some config options into software configs from some outdated how-to or StackOverflow and OK with now knowing what a given option does and if it is relevant in given case. May be with autotools it happens more often than with cmake (though I've seen enough bad CMakeLists.txt too) because there is a myth that autotools is very hard to learn so developer don't even try to read documentation and just put some random stuff into their .ac/.am files until it works for them albeit slow.
  - account42 6y ago
    If the configure tests were part of the dependency graph for parallel exection then any unneeded checks would simply not be run because nothing depends on them.

drewg123 6y ago

It was born in an era when there were many different *nix versions, all slightly different, with different names for include files, different C compilers with different flags, etc. Different OSes took differing numbers of arguments to certain library functions, etc. It was a necessary evil in the 90s. I still remember the perl config script that would say "Congratulations. You aren't running Eunice!" (Eunice was a bsd unix compat layer for VMS)