You could setup a `config.site` 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 need. On Wed, Apr 27, 2022, 8:24 AM R. Diez <rdiezmail-temp2@xxxxxxxx> wrote: > Hi all: > > I have this cross-compiling Autoconf project: > > https://github.com/rdiez/JtagDue/tree/master/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 > >
