Re: make installcheck-world in a clean environment - Mailing list pgsql-hackers

From Tom Lane
Subject Re: make installcheck-world in a clean environment
Date
Msg-id 26960.1532994120@sss.pgh.pa.us
Whole thread Raw
In response to Re: make installcheck-world in a clean environment  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: make installcheck-world in a clean environment
List pgsql-hackers
I wrote:
> The original complaint about ecpg remains; I'm not terribly excited
> about messing with that.

Well, I got curious as to why we were seeing such a weird error,
and eventually traced it to this stuff in ecpg/test/Makefile.regress:

# Standard way to invoke the ecpg preprocessor
ECPG = ../../preproc/ecpg --regression -I$(srcdir)/../../include -I$(srcdir)

# Files that most or all ecpg preprocessor test outputs depend on
ECPG_TEST_DEPENDENCIES = ../../preproc/ecpg$(X) \
    $(srcdir)/../regression.h \
    $(srcdir)/../../include/sqlca.h \
    $(srcdir)/../../include/sqlda.h \
    $(srcdir)/../../include/sqltypes.h \
    $(srcdir)/../../include/sql3types.h

%.c: %.pgc $(ECPG_TEST_DEPENDENCIES)
    $(ECPG) -o $@ $<

Now, the fine gmake manual quoth:

    `%' in a prerequisite of a pattern rule stands for the same stem
    that was matched by the `%' in the target.  In order for the pattern
    rule to apply, its target pattern must match the file name under
    consideration and all of its prerequisites (after pattern substitution)
    must name files that exist or can be made.

So the problem is that (after make clean) ../../preproc/ecpg doesn't
exist, and the Makefiles under test/ have no idea how to build it,
and thus this pattern rule is inapplicable.  Thus you end up getting
"No rule to make target" errors.

While it seems straightforward to fix this for "make check" scenarios ---
just go make ecpg before trying to make the tests --- I think these rules
are very surprising for "make installcheck" cases.  You'd expect "make
installcheck" to test the installed ecpg, as indeed Alexander pointed out
at the start of the thread.  But it's not doing that.

Alexander's USE_INSTALLED_ASSETS patch attempted to fix that, and I now
see the point of it, but it still seems pretty hacky and invasive (why
should an ecpg-only problem be touching stuff outside ecpg)?  Also,
unless I'm still missing something, it doesn't fix the problem with
"make clean check": ecpg won't have been built before we try to build the
test programs.

I'd suggest trying to simplify the USE_INSTALLED_ASSETS patch so it
doesn't muck with the rules for building pg_regress.  I don't find
that to be very relevant to the problem.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Recovery performance of standby for multiple concurrent truncateson large tables
Next
From: David Rowley
Date:
Subject: Re: Making "COPY partitioned_table FROM" faster