Re: make installcheck-world in a clean environment

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