[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
signature.asc
Description: This is a digitally signed message part.