Re: failing to build preproc.c on solaris with sun studio

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

In response to

Browse pgsql-hackers by date

  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