From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Max Filippov <jcmvbkbc(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Peter Seiderer <ps(dot)report(at)gmx(dot)net> |
Subject: | Re: configure can't detect proper pthread flags |
Date: | 2015-03-20 12:13:16 |
Message-ID: | 20150320121316.GG6317@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Mar 20, 2015 at 08:05:48AM -0400, Robert Haas wrote:
> On Fri, Mar 20, 2015 at 7:01 AM, Max Filippov <jcmvbkbc(at)gmail(dot)com> wrote:
> > On Fri, Mar 20, 2015 at 6:08 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> We don't want every link step producing a useless warning.
> >> Ideally, "make -s" would print nothing whatsoever; to the extent that
> >> tools produce unsuppressable routine chatter, that's evil because it
> >> makes it harder to notice actually-useful warnings.
> >
> > Then maybe stderr tests should grep output for a specific option, the
> > one we're currently testing, not just any noise?
>
> That sounds awfully fragile to me. It can't really be safe to assume
> we know precisely what the warning messages will look like. But it
> seems to me that compiling every test program with every library we
> might need is not a great plan.
>
> (I don't know enough about autoconf to know whether changing that is realistic.)
It was our only plan, and it has worked fine in the past. Someone is
going to have to do a lot of portability research to improve it.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2015-03-20 12:31:24 | Re: Incorrect comment in tablecmds.c |
Previous Message | Thom Brown | 2015-03-20 12:09:00 | Re: assessing parallel-safety |