Thread: libpq_pipeline in tmp_install

The test program libpq_pipeline produced by the test suite in 
src/test/modules/libpq_pipeline/ is installed into tmp_install as part 
of make check.  This isn't a real problem by itself, but I think it 
creates a bit of an asymmetric situation that might be worth cleaning up.

Before, the contents of tmp_install exactly matched an actual 
installation.  There were no extra test programs installed.

Also, the test suite code doesn't actually use that installed version, 
so it's not of any use, and it creates confusion about which copy is in use.

The reason this is there is that the test suite uses PGXS to build the 
test program, and so things get installed automatically.  I suggest that 
we should either write out the build system by hand to avoid this, or 
maybe extend PGXS to support building programs but not installing them. 
The advantage of the former approach is that it would allow additional 
test programs to be added later as well.  (We should really collect the 
libpq tests under src/interfaces/libpq/ anyway at some point.)

On 10.05.21 20:26, Peter Eisentraut wrote:
> The test program libpq_pipeline produced by the test suite in 
> src/test/modules/libpq_pipeline/ is installed into tmp_install as part 
> of make check.  This isn't a real problem by itself, but I think it 
> creates a bit of an asymmetric situation that might be worth cleaning up.
> 
> Before, the contents of tmp_install exactly matched an actual 
> installation.  There were no extra test programs installed.
> 
> Also, the test suite code doesn't actually use that installed version, 
> so it's not of any use, and it creates confusion about which copy is in 
> use.
> 
> The reason this is there is that the test suite uses PGXS to build the 
> test program, and so things get installed automatically.  I suggest that 
> we should either write out the build system by hand to avoid this, or 
> maybe extend PGXS to support building programs but not installing them. 

Here is a patch that implements the second solution, which turned out to 
be very easy.

Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> On 10.05.21 20:26, Peter Eisentraut wrote:
>> The reason this is there is that the test suite uses PGXS to build the 
>> test program, and so things get installed automatically.  I suggest that 
>> we should either write out the build system by hand to avoid this, or 
>> maybe extend PGXS to support building programs but not installing them. 

> Here is a patch that implements the second solution, which turned out to 
> be very easy.

+1, except that you should add documentation for NO_INSTALL to the
list of definable symbols at the head of pgxs.mk, and to the list
in extend.sgml (compare that for NO_INSTALLCHECK).

            regards, tom lane

On 2021-May-19, Tom Lane wrote:

> Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> > On 10.05.21 20:26, Peter Eisentraut wrote:
> >> The reason this is there is that the test suite uses PGXS to build the 
> >> test program, and so things get installed automatically.  I suggest that 
> >> we should either write out the build system by hand to avoid this, or 
> >> maybe extend PGXS to support building programs but not installing them. 
> 
> > Here is a patch that implements the second solution, which turned out to 
> > be very easy.

Great, thank you.

> +1, except that you should add documentation for NO_INSTALL to the
> list of definable symbols at the head of pgxs.mk, and to the list
> in extend.sgml (compare that for NO_INSTALLCHECK).

I propose this.

-- 
Álvaro Herrera       Valdivia, Chile

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2021-May-19, Tom Lane wrote:
>> +1, except that you should add documentation for NO_INSTALL to the
>> list of definable symbols at the head of pgxs.mk, and to the list
>> in extend.sgml (compare that for NO_INSTALLCHECK).

> I propose this.

WFM.

            regards, tom lane

On 19.05.21 19:35, Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
>> On 2021-May-19, Tom Lane wrote:
>>> +1, except that you should add documentation for NO_INSTALL to the
>>> list of definable symbols at the head of pgxs.mk, and to the list
>>> in extend.sgml (compare that for NO_INSTALLCHECK).
> 
>> I propose this.
> 
> WFM.

Thanks for the feedback.  I found that my proposal doesn't quite work, 
because "check" doesn't depend on "all" (anymore; see dbf2ec1a1c0), so 
running make check-world doesn't build the test program first.  The 
easiest workaround I found was to add an "install: all" line even for 
the NO_INSTALL case.  It's all a bit hackish, though.