Re: [HACKERS] pgsql: Refactor flex and bison make rules

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] pgsql: Refactor flex and bison make rules
Дата
Msg-id 19776.1354146592@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] pgsql: Refactor flex and bison make rules  (Andrew Dunstan <andrew@dunslane.net>)
Список 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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: [HACKERS] pgsql: Refactor flex and bison make rules
Следующее
От: Tom Lane
Дата:
Сообщение: pgsql: Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.