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 incorrect results.
I think an easier way is to configure two vpath builds and install the
pieces you want from each one. yo
> 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 something about that.
> which means that we might end up having to copy all the source files
> into a new plpython3 subdirectory anyway. We're already doing some of
> that with the regression test files, though.
Doing it with the test files is already annoying enough. For instance,
we don't have a static list of all the files we need to copy (because of
expected file variants that are not tracked in the makefiles), so we
need to copy the files again on each run. If you extend this to all
source files, things would get totally bizarre.
A less invasive method might be to set up a second directory
pl/plpython3 which vpath-builds from pl/plpython.
But frankly, I'd like to work on the multiple-shlibs-in-one-directory
issue, because all of the above issues and more are projected in their
own strange ways on something like the transforms feature. For example,
how would you organize the source code for an extension module that
provides a new data type and adapters for plpython{2,3}u and plperl{,u},
with tests and all that?
