Re: make installcheck-world in a clean environment

Alexander Lakhin <exclusion(at)gmail(dot)com> writes:
> 31.07.2018 02:42, Tom Lane wrote:
>> 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.

Well, there's a lot of moving parts here, and it's not clear to me what
makes the most sense. We potentially have the following things that
ECPG "make check" generates or references in the build tree, but we might
wish for "make installcheck" to use preinstalled versions of instead:

1. Server executables and other "installed" server support files.
2. PG cluster (datadir and running server).
3. pg_regress and libraries it depends on, such as libpq.
4. ecpg preprocessor.
5. ecpg's exported C header files, needed to compile test programs.
6. ecpg's libraries, used by test programs; also libpq.

Currently, installcheck references an existing running cluster (#2)
and therefore a fortiori #1 as well. That's fine. I believe we
reference a local pg_regress and libraries (#3) in both cases,
and that's also fine, because we don't install pg_regress at all.
(Well, PGXS does, but ecpg tests shouldn't rely on that.)
So it boils down to what to do about #4/#5/#6.

I suppose we could define "make installcheck" as referring only
to using an installed server, not any ecpg support, in which
case we don't need any big surgery to the ecpg makefiles.
I'm not sure how consistent a definition that is, but maybe it
makes sense by analogy to pg_regress.

Another point here is that if you did "make check" and then
"make installcheck", it presumably would not rebuild the test
programs, meaning they'd still have been built using the local
resources not the installed ones (or vice versa for the other
order). So there's also a difference between "build" and
"test execution", which seems relevant, and it's one we don't
really have any make-target nomenclature to distinguish.

Given that you'd expect "make all" to use local copies of the
build resources, perhaps there should be a separate target
named along the lines of "make tests-from-install" that uses
installed ecpg+other resources to compile the test programs.

Anyway, as long as the installcheck target is dependent on "all" not
something else, maybe it's fine as is. I'm definitely not sure what
would be a consistent design for doing it differently.

regards, tom lane