Supporting plpython 2+3 builds better

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Supporting plpython 2+3 builds better
Date: 2012-09-08 23:18:43
Message-ID: 6480.1347146323@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> After reading the recent thread about python 2 vs python 3 support,
> I thought I'd amuse myself by trying to get plpython3 supported in
> the Fedora packages. That turned out to be unreasonably painful
> (which is something we oughta fix eventually), but it worked,

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 we really need to do something to make this type of build less
painful, because as far as I can see most distros are going to be
wanting to support both python 2 and 3 for awhile to come.

A sketch of a solution might go like this:

* Extend configure to have two switches, say "--with-python" and
"--with-python3", which you can select either or both of. If you
want to pick executables that are not named "python" and "python3",
perhaps write it like "--with-python3=/usr/bin/python3.2mu". (I'd
be inclined to remove the dependency on a PYTHON envvar altogether.)

* Make configure output two independent sets of variables into
Makefile.global, viz

python2_includespec = ...
python2_libdir = ...
python2_libspec = ...
python2_additional_libs = ...
python2_configdir = ...
python2_majorversion = ...
python2_version = ...

python3_includespec = ...
python3_libdir = ...
python3_libspec = ...
python3_additional_libs = ...
python3_configdir = ...
python3_majorversion = ...
python3_version = ...

* Make plpython's Makefile build, test, install plpython2 and/or
plpython3 depending on what's set in Makefile.global.

I'm not sure yet whether it's possible to do this without duplicating a
lot of logic in config/python.m4 and plpython's Makefile.

Another problem is that Makefile.shlib isn't designed to build more than
one shared library per directory, 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.

Thoughts?

regards, tom lane

Attachment Content-Type Size
python-2-and-3.patch text/x-patch 6.6 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2012-09-08 23:20:37 Re: build farm machine using <make -j 8> mixed results
Previous Message Josh Berkus 2012-09-08 22:27:33 Re: pg_test_fsync output and commit_delay