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
