From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, Michael Meskes <meskes(at)postgresql(dot)org>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: failing to build preproc.c on solaris with sun studio |
Date: | 2022-09-05 21:30:04 |
Message-ID: | 20220905213004.evaazio3wnjz77to@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2022-09-05 22:52:03 +0200, Peter Eisentraut wrote:
> On 04.09.22 16:55, Tom Lane wrote:
> > I guess we could proceed like this:
> >
> > 1. Invent the --with option. Temporarily make "make check" in ecpg
> > print a message but not fail if the option wasn't selected.
> >
> > 2. Update buildfarm client to recognize the option and skip ecpg-check
> > if not selected.
> >
> > 3. Sometime down the road, after everyone's updated their buildfarm
> > animals, flip ecpg "make check" to throw an error reporting that
> > ecpg wasn't built.
>
> Why is this being proposed?
On slower machines / certain platforms it's the bottleneck during compilation
(as e.g. evidenced in this thread). There's no proper way to run check-world
exempting ecpg. Most changes don't involve ecpg in any way, so having every
developer build preproc.o etc isn't necessary.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-09-05 21:34:41 | Re: failing to build preproc.c on solaris with sun studio |
Previous Message | Peter Eisentraut | 2022-09-05 20:52:03 | Re: failing to build preproc.c on solaris with sun studio |