[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bash-bug
Subject:    Re: Parallelization of shell scripts for 'configure' etc.
From:       Alex Ameen <alex.ameen.tx () gmail ! com>
Date:       2022-07-09 1:16:11
Message-ID: CAKgHvysZuOcGvgnV1E6_KLfKy5oLwJP4B046DEMUZirv81xe5A () mail ! gmail ! com
[Download RAW message or body]

I've been telling folks about the config site file every time this thread
comes up. Good on you for actually trying it haha.

It can make a huge difference. You can short circuit a lot of checks this
way.

Now, the disclaimer: you still shouldn't share a cache file between
projects, and if you use a `config.site` don't stash internal values. Be
sure you keep an eye on your `config.site` values as your system is updated
over time, and if you use containers or build in chroots keep in mind how
that can effect the validity of your cache and `config.site` settings.



On Fri, Jul 8, 2022, 3:05 PM Simon Josefsson via Discussion list for the
autoconf build system <autoconf@gnu.org> wrote:

> Tim Rühsen <tim.ruehsen@gmx.de> writes:
> 
> > a) The maintainer/contributor/hacker setup
> > This is when you re-run configure relatively often for the same
> project(s).
> > I do this normally and and came up with
> > 
> https://gitlab.com/gnuwget/wget2/-/wikis/Developer-hints:-Increasing-speed-of-GNU-toolchain.
>  
> > It may be a bit outdated, but may help one or the other here.
> > Btw, I am down to 2.5s for a ./configure run from 25s originally.
> 
> Wow, I think more developers should known about your final suggestion:
> 
> 
> https://gitlab.com/gnuwget/wget2/-/wikis/Developer-hints:-Increasing-speed-of-GNU-toolchain#cccflags-dependent-usage-of-configure-caching
>  
> That is, put this in ~/.bash_aliases:
> 
> export CONFIG_SITE=~/src/config.site
> 
> and this in ~/src/config.site:
> 
> if test "$cache_file" = /dev/null; then
> hash=`echo $CFLAGS $LDFLAGS $host_alias $build_alias|md5sum|cut -d' '
> -f1`
> cache_file=~/src/config.cache.$CC.$hash
> fi
> 
> The top of config.log says which cache file was used, so you can remove
> it when you hack on autoconf/M4 macros.
> 
> This appears to save me tons of build time, and I'll run with this now
> since it is non-obtrusive and doesn't require changes in each project...
> maybe the CWD should be put into the cache_file string to avoid cache
> poisining between projects, but that is minor.
> 
> /Simon
> 


[prev in list] [next in list] [prev in thread] [next in thread]