Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

configure with --cache-file should be faster #7753

Closed
tlhackque opened this issue Sep 22, 2021 · 1 comment
Closed

configure with --cache-file should be faster #7753

tlhackque opened this issue Sep 22, 2021 · 1 comment

Comments

@tlhackque
Copy link

In building the latest release, I noticed that many apparently cachable configure responses aren't coming from the cache.

configure runs much faster when results are cached. (Including on developer's machines...)
see https://www.gnu.org/software/autoconf/manual/autoconf-2.60/html_node/Cache-Files.html & https://www.gnu.org/software/autoconf/manual/autoconf-2.60/html_node/Caching-Results.html#Caching-Results

I did this

./configure --prefix=/usr --with-nghttp2=/usr/local --with-libssh2=/usr/local --enable-ares --with-openssl \
--cache-file=../curl.cache

I expected the following

most output includes "(cached)", like (representative, many lines removed)

checking for gcc... (cached) gcc
checking for suffix of object files... (cached) o
checking whether the compiler supports GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to enable C11 features... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking how to run the C preprocessor... (cached) gcc -E
checking for stdio.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for inttypes.h... (cached) yes
checking for stdint.h... (cached) yes
checking for strings.h... (cached) yes
checking for sys/stat.h... (cached) yes
checking for sys/types.h... (cached) yes
checking for unistd.h... (cached) yes

But I get a lot of uncached output (again, representative):

checking if cpp -P is needed... yes
checking if cpp -P works... yes
checking if compiler is DEC/Compaq/HP C... no
checking if compiler is HP-UX C... no
checking if compiler is IBM C... no
checking if compiler is Intel C... no
checking if compiler is clang... no
checking if compiler is GNU C... yes
checking if compiler is LCC... no
checking if compiler is SGI MIPSpro C... no
checking if compiler is SGI MIPS C... no
checking if struct sockaddr_in6 has sin6_scope_id member... yes
checking if alarm can be linked... yes
checking if alarm is prototyped... yes
checking if alarm is compilable... yes
checking if alarm usage allowed... yes
checking if alarm might be used... yes
checking if freeaddrinfo can be linked... yes
checking if freeaddrinfo is prototyped... yes
checking if freeaddrinfo is compilable... yes
checking if freeaddrinfo usage allowed... yes
checking if freeaddrinfo might be used... yes
checking if fsetxattr can be linked... yes
checking if fsetxattr is prototyped... yes
checking if fsetxattr takes 5 args.... yes
checking if getaddrinfo is threadsafe... yes

curl/libcurl version

curl 7.79.1 (i686-pc-linux-gnu) libcurl/7.79.1 OpenSSL/1.1.1d zlib/1.2.11 brotli/1.0.7 zstd/1.4.9 c-ares/1.15.0 libssh2/1.8.2 nghttp2/1.37.0 OpenLDAP/2.4.47
Release-Date: 2021-09-22
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTPS-proxy IPv6 Largefile libz NTLM NTLM_WB SSL TLS-SRP UnixSockets zstd

operating system

Any OS using configure - here's one
Linux overkill 2.6.22.14-100 #1 SMP Wed Apr 8 18:07:54 EDT 2015 i686 i686 i386 GNU/Linux

I know this isn't a functional issue, but caching does make a huge difference - especially on older/slower hardware. But it also adds up if you're running CI tests, so it would be good for developers too :-)

It's the kind of thing that can easily be done incrementally - you just add AC_CACHE_CHECK or AC_CACHE_VAL wrappers around your existing tests as time allows. (In my projects, I tend to do it while waiting for configure to run...)

@bagder
Copy link
Member

bagder commented Sep 24, 2021

This (proper configure results caching) has been suggested and discussed a few times before but nobody has ever gotten around to actually make it happen. It risks "just" getting added to the TODO docs now as well unless someone volunteers to work on it.

@bagder bagder closed this as completed in c9c1bfb Sep 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants