Re: shared_libperl, shared_libpython

On 04/28/2015 04:31 PM, Peter Eisentraut wrote:
> 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?
>
>

In general I prefer things not being available to be tested at configure
time. After all, we check for libxml2, for example. Certainly silent
failure is a bad thing.

cheers

andrew