shared_libperl, shared_libpython

On 4/28/15 12:05 AM, Tom Lane wrote:
> Yeah. Even more specifically, olinguito does have --with-python in its
> configure flags, but then the plpython Makefile skips the build because
> libpython isn't available as a shared library. But the contrib test is
> (I assume, haven't looked) conditional only on the configure flag.
>
> I'm not real sure now why we felt that was a good approach. The general
> project policy is that if you ask for a feature in the configure flags,
> we'll build it or die trying; how come this specific Python issue gets
> special treatment contrary to that policy?
>
> So I'd vote for changing that to put the shared-library test in configure,
> or at least make it a build failure later on, not "silently don't build
> what was asked for". That would mean olinguito's configure flags would
> have to be adjusted.
>
> Plan B would require propagating the shared-libpython test into the
> contrib makefiles, which seems pretty unpalatable even if you're willing
> to defend the status quo otherwise.

I had tried plan B prime, moving the shared_libpython etc. detection
into Makefile.global. But that doesn't work because contrib/pgxs
makefiles require setting all variables *before* including the global
makefiles. So you can't decide whether you want to build something
before you have told it everything you want to build.

The reason for the current setup is actually that when plperl and later
plpython was added, we still had Perl and Python client modules in our
tree (Pg.pm and pygresql), and configure --with-perl and --with-python
were meant to activate their build primarily. Also, in those days,
having a shared libperl or libpython was rare. But we didn't want to
fail the frontend interface builds because of that. So we arrived at
the current workaround.

My preference would be to rip all that out and let the compiler or
linker decide when it doesn't want to link something.

The alternative would be creating a configure check that mirrors the
current logic. Arguably, however, the current logic is quite unworthy
of a configure check, because it's just a collection of
on-this-platform-do-that, instead of a real test. Then again, a real
test would require building and loading a shared library in configure,
and we are not set up for that.

Preferences?