Re: make installcheck-world in a clean environment

31.07.2018 02:42, Tom Lane wrote:
> 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.
Yes, it's exactly the problem I was trying to fix.
> 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.
In fact, after fixing ECPG usage with installcheck, I found that "make
installcheck" then rebuilds libpostgres, libpgport and libpq (for
installcheck-world). (I mentioned it in this thread before.) Later I
proposed a more comprehensive patch that allows us to make installcheck
cleanly (without building something).
So the problem is not ecpg-only, the ecpg's failure to build is
prominent part of it, but there are another assets getting built under
the hood.
> 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.
I can simplify the patch to fix only the ECPG failure, and then prepare
a distinct patch for libs, if it makes sense.

Best regards,
------

Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company