[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Accelerate the 'configure' script

From: Alex Ameen
Subject: Re: Accelerate the 'configure' script
Date: Wed, 27 Apr 2022 12:04:32 -0500

You could setup a `` file to share across projects. This is
where I imagine you will get the most mileage.

But it sounds like you can probably recycle `config.cache` for a single
pipeline assuming you aren't changing the actual configure script and
external inputs.

I saw your other message to the `automake` list; it sounds like you're
trying to shave fractions of a second off of your build time. With that in
mind I think you're inevitably going to need to go down the rabbit hole of
learning the internals of `autotools` to get the kind of optimization you

On Wed, Apr 27, 2022, 8:24 AM R. Diez <> wrote:

> Hi all:
> I have this cross-compiling Autoconf project:
> I am not using Autoconf for portability, but mainly for handling C/C++
> dependencies, so that not everything is rebuilt when I change one source
> file.
> This is just an example project, I have others that are bigger, and I
> rebuild many of them automatically overnight. That is why I am looking at
> speeding up the configuration process.
> The example project above does the following checks:
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for arm-none-eabi-strip... arm-none-eabi-strip
> checking for a race-free mkdir -p... /bin/mkdir -p
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking whether make supports nested variables... yes
> checking whether make supports nested variables... (cached) yes
> checking for arm-none-eabi-gcc... ccache arm-none-eabi-gcc
> checking whether we are cross compiling... yes
> checking for suffix of object files... o
> checking whether the compiler supports GNU C... yes
> checking whether ccache arm-none-eabi-gcc accepts -g... yes
> checking for ccache arm-none-eabi-gcc option to enable C11 features...
> none needed
> checking whether ccache arm-none-eabi-gcc understands -c and -o
> together... yes
> checking whether make supports the include directive... yes (GNU style)
> checking dependency style of ccache arm-none-eabi-gcc... gcc3
> checking whether the compiler supports GNU C++... yes
> checking whether ccache arm-none-eabi-g++ accepts -g... yes
> checking for ccache arm-none-eabi-g++ option to enable C++11 features...
> none needed
> checking dependency style of ccache arm-none-eabi-g++... gcc3
> checking dependency style of ccache arm-none-eabi-gcc... gcc3
> checking for arm-none-eabi-ranlib... arm-none-eabi-gcc-ranlib
> Is there a way to speed these checks up? The platform is always a
> reasonably modern Linux, the compiler is always GCC, and ccache is always
> at least version 3.7.7, so most checks are unnecessary (for me).
> Things I can think of:
> - 'install' can be assumed to be OK.
> - 'mkdir' can be assumed to be OK.
> - I am always using GNU Make, so all 3 checks around make are dispensable.
> - I am always using GCC, so checking whether it accepts -g etc. is not
> necessary.
> Is there any article or blog post somewhere with speed-up hints for
> Autoconf?
> I am aware that Autoconf has an optional config cache, but this time I am
> specifically looking for other ways.
> One of the problems of the config cache is that I cannot share a
> config.cache for all possible build types of one project, let alone
> different projects. What I mean is that, if I configure the project above
> in different out-of-tree subdirectories (one for an ARM target as a debug
> build, another one for an Intel target as a release build, etc.), then I
> cannot easily share a global configure.cache with only the result of global
> checks like "whether mkdir -p" is race free.
> Even if I managed to share one config.cache, I am not sure that multiple
> projects building in parallel would not corrupt it (race condition). That
> is not documented as far as I can tell.
> I could try to generate a fake cache file, but that is not
> straightforward, and it is always somewhat brittle. For example, you cannot
> easily guarantee that the pre-calculated cache entries are actually being
> used by the next Autoconf version.
> Thanks in advance,
>    rdiez

reply via email to

[Prev in Thread] Current Thread [Next in Thread]