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
