bug-gnulib
[Top][All Lists]
Advanced

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

Re: manywarnings.m4 optimization request


From: Tim Rühsen
Subject: Re: manywarnings.m4 optimization request
Date: Sun, 30 Oct 2016 18:08:21 +0100
User-agent: KMail/5.2.3 (Linux/4.7.0-1-amd64; KDE/5.27.0; x86_64; ; )

On Samstag, 29. Oktober 2016 10:09:01 CET Jim Meyering wrote:
> On Fri, Oct 28, 2016 at 7:05 AM, Tim Ruehsen <address@hidden> wrote:
> > Hi,
> > 
> > during some GNU internal discussion I was asked to post my proposal /
> > request here.
> > 
> > "I use manywarnings.m4 in my projects which take ~9s here (~25% of the
> > whole ./configure run).
> > One gcc invocation per (possible) warning options sums up a lot.
> > 
> >   gcc -Q --help=warning|awk '{ if ($2 == "[disabled]") print $1 }'
> > 
> > gives a complete list of available warning options which we can use
> > without
> > checking each single option.
> > This also takes automatic advantage of new gcc warnings."
> > 
> > 
> > I took a look at the source but feel somewhat incompetent to provide a
> > patch (m4 and shell is just not my competence). It seems to be a pretty
> > low-hanging fruit for an expert, though.
> > 
> > I really would enjoy a faster manywarnings.m4 !
> 
> Good idea.
> Just a matter of someone getting motivated and finding the time.

I hope someone finds the motivation.
It would of great help though, if someone could lead me to the (.m4 ?) files to 
change and/or needed functionality. Than i could produce a patch prototype 
that can be polished here.

> In the mean time, do you use a ./configure cache?
> In day-to-day runs of configure, I rarely notice this, because my
> initial invocation of ./configure usually includes e.g.,
> `--cache=.cache`.
> 
> Of course, if you're always building from a just-unpacked tarball,
> that doesn't help. In that case, you can use an absolute name or the
> CONFIG_SITE envvar, per
> https://www.gnu.org/software/autoconf/manual/autoconf-2.68/html_node/Site-De
> faults.html.

Thanks for the hints.
I use -C whenever possible, but developing means here testing all kinds of 
compiler versions and CFLAGS combinations. This involves lot's of ./configure 
runs without caching.
Since ./configure doesn't scale up with number of cpu cores... you just can't 
imagine how long a ./configure run takes on of my OpenSolaris Sparc test 
machines (~5-6 minutes). This is just wasting precious developer time...

But I give config.site a closer look...

Tim

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

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