Обсуждение: 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?
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
Peter Eisentraut <peter_e@gmx.net> writes:
> 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?
> 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.
Ah. I'm glad you remember, because I didn't.
> My preference would be to rip all that out and let the compiler or
> linker decide when it doesn't want to link something.
Works for me, assuming that we get an understandable failure message and
not, say, a plperl.so that mysteriously doesn't work.
regards, tom lane
On Wed, Apr 29, 2015 at 12:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Peter Eisentraut <peter_e@gmx.net> writes: >> 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? > >> 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. > > Ah. I'm glad you remember, because I didn't. Interesting, those are pieces of history: commit: f10a9033bf308f9dde0aa77caad6503e233489d1 author: Peter Eisentraut <peter_e@gmx.net> date: Mon, 1 Sep 2003 23:01:49 +0000 Clean up after pygresql removal: adjust/remove documentation and remove unneeded configure work. commit: 9a0b4d7f847469544798133391e221481548e1b9 author: Marc G. Fournier <scrappy@hub.org> date: Fri, 30 Aug 2002 13:06:22 +0000 perl5 interface moved to gborg >> My preference would be to rip all that out and let the compiler or >> linker decide when it doesn't want to link something. > > Works for me, assuming that we get an understandable failure message and > not, say, a plperl.so that mysteriously doesn't work. +1. -- Michael
On 4/28/15 11:48 PM, Tom Lane wrote: >> My preference would be to rip all that out and let the compiler or >> linker decide when it doesn't want to link something. > > Works for me, assuming that we get an understandable failure message and > not, say, a plperl.so that mysteriously doesn't work. Well, I can't really guarantee that, and I also recall that in some cases a shared/non-shared mismatch will work but be slow or something like that. So I went for the configure detection. For Perl, this is straightforward. For Python and Tcl, it gets tricky because they look at the actual file in some cases, which requires knowing DLSUFFIX, which is not available in configure. (And it's a lie anyway, because on OS X it does not distinguish between .so and .dylib in a principled way.) For Tcl, this is only necessary for version before Tcl 8.0 (according to code comments), which I think we can safely drop. For Python, it's still necessary, so I hardcoded a few choices in an ugly way. I think overall this patch is still an improvement in several ways. Worst case, we could turn some of these configure errors into warnings.