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 по дате отправления: