Re: [HACKERS] pgsql: Refactor flex and bison make rules - Mailing list pgsql-committers

From Tom Lane
Subject Re: [HACKERS] pgsql: Refactor flex and bison make rules
Date
Msg-id 19776.1354146592@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] pgsql: Refactor flex and bison make rules  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-committers
Andrew Dunstan <andrew@dunslane.net> writes:
> On 11/28/2012 06:19 PM, Tom Lane wrote:
>> It appears to me that the case that okapi is hitting is specific to the
>> ecpg preprocessor build rules, and indeed specific to the case where
>> preproc.c needs to be rebuilt.  A .NOTPARALLEL in ecpg/preproc/Makefile
>> would probably be enough to fix it.  (I'm a bit tempted to make the one
>> already added to ecpg/Makefile conditional on the make version, as you
>> suggest above, too.)

> There is something odd about okapi, because my linux/gcc buildfarm
> animal is using make 3.82 happily, with make_jobs = 4.

Yeah, and nobody else has seen this either.  It might just be that okapi
has exactly the right number of processors with exactly the right speeds
to make the failure a lot more probable.  Or maybe there's something
weird about Gentoo's version of make (wouldn't be the first time).

Anyway, deparallelizing just the ecpg/preproc build would cost very
little in build time, since it's totally dominated by the preproc.c and
preproc.o build steps anyway.  I'm inclined to just do it and see if
the problem goes away.

            regards, tom lane


pgsql-committers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [HACKERS] pgsql: Refactor flex and bison make rules
Next
From: Tom Lane
Date:
Subject: pgsql: Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.