Re: BUG #6198: init-po fails for plperl due to invalid xsubpp path (contains ExtUtils) - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #6198: init-po fails for plperl due to invalid xsubpp path (contains ExtUtils)
Date
Msg-id 10209.1315179148@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #6198: init-po fails for plperl due to invalid xsubpp path (contains ExtUtils)  (Alex Hunsaker <badalex@gmail.com>)
List pgsql-bugs
Alex Hunsaker <badalex@gmail.com> writes:
> On Sun, Sep 4, 2011 at 16:57, Tomas Vondra <tv@fuzzy.cz> wrote:
>> Aha! When I run configure like this
>>
>> $ ./configure --with-perl --enable-nls=cs

> Whoa, I totally missed that it was without --with-perl. :-)

>> then it works, so obviously the "--with-perl" option is required.
>> Shouldn't this behave a bit differently, e.g. not allowing "enable-nls"
>> without "with-perl"? Allowing that and getting not-fully-working tree is
>> not a good thing I guess ...

> Hrm, I don't know much about the nls stuff... but it seems like a
> reasonable request to me.

Uh, no, because init-po is not needed by mere users of existing
translations.  Nor does somebody who wants --enable-nls necessarily
care about building plperl.  The failure here is not about combining NLS
with --without-perl, it's about trying to do anything at all with plperl
with --without-perl.

I'd say the fix is to make plperl's makefile defend itself against
somebody cd'ing to that directory and trying to use the makefile without
having configured correctly.

Another question worth asking is why is the rule being run at all?
Do we need to have built SPI.c in order to do init-po for plperl?

            regards, tom lane

pgsql-bugs by date:

Previous
From: Alex Hunsaker
Date:
Subject: Re: BUG #6198: init-po fails for plperl due to invalid xsubpp path (contains ExtUtils)
Next
From: Ashesh Vashi
Date:
Subject: Re: BUG #6194: Cannot install any of the installers