Re: [HACKERS] Supporting plpython 2+3 builds better

2012-09-10 Thread Peter Eisentraut
On 9/10/12 9:26 AM, Alvaro Herrera wrote: > I remember trying to do this for the mb/conversion_procs subdir years > ago, to make them build in parallel to save some time. It didn't go > anywhere but the basic idea seems similar in spirit. Maybe we can use > this there too to make it fast. Parall

Re: [HACKERS] Supporting plpython 2+3 builds better

2012-09-10 Thread Alvaro Herrera
Excerpts from Peter Eisentraut's message of lun sep 10 09:50:42 -0300 2012: > On Sun, 2012-09-09 at 03:35 -0400, Tom Lane wrote: > > >> Another problem is that Makefile.shlib isn't designed to build more > > >> than one shared library per directory, > > > > > That's the main problem, but fixing it

Re: [HACKERS] Supporting plpython 2+3 builds better

2012-09-10 Thread Peter Eisentraut
On Sun, 2012-09-09 at 03:35 -0400, Tom Lane wrote: > >> Another problem is that Makefile.shlib isn't designed to build more > >> than one shared library per directory, > > > That's the main problem, but fixing it would be very useful in other > > places as well. I had it on my radar to do somethi

Re: [HACKERS] Supporting plpython 2+3 builds better

2012-09-09 Thread Tom Lane
Peter Eisentraut writes: > On Sat, 2012-09-08 at 19:18 -0400, Tom Lane wrote: >> To give you an idea of what "unreasonably painful" means, attached is >> the specfile diff needed to make this happen. I will not comment on >> the fragility of this beyond observing that the "touch -r" commands >> a

Re: [HACKERS] Supporting plpython 2+3 builds better

2012-09-08 Thread Peter Eisentraut
On Sat, 2012-09-08 at 19:18 -0400, Tom Lane wrote: > To give you an idea of what "unreasonably painful" means, attached is > the specfile diff needed to make this happen. I will not comment on > the fragility of this beyond observing that the "touch -r" commands > are *necessary*, else you get inc