Re: make installcheck-world in a clean environment - Mailing list pgsql-hackers
From | Alexander Lakhin |
---|---|
Subject | Re: make installcheck-world in a clean environment |
Date | |
Msg-id | 8d6aebaa-d119-b702-f8a3-e0261e4cb586@gmail.com 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 |
31.07.2018 02:42, Tom Lane wrote:
Yes, it's exactly the problem I was trying to fix.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.
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).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.
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 can simplify the patch to fix only the ECPG failure, and then prepare a distinct patch for libs, if it makes sense.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.
Best regards,
------
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
pgsql-hackers by date: