Re: make installcheck-world in a clean environment - Mailing list pgsql-hackers

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 would split 3 to:
3. client libraries, such as libpq.
7. pg_regress.
I missed the fact that pg_regress is installed in lib/pgxs/src/test/regress/, and now it raises a question for me - why this pg_regress instance should be used only for PGXS tests?
Leaving the question aside, I propose the fix to use the preinstalled versions of 3-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.

Yes, this is important question and I have no complete answer for now, but maybe these test programs could be built as temporary?

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.

If I understand you correctly, the attached patch does just this.
To illustrate it I also attached the log of "make -C src/interfaces/ecpg; make installcheck" and the log of "make installcheck" with patch applied (both procedures executed immediately after "make clean").

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.

I would propose the following design for "make installcheck":
1. For every thing that has installed version, use it.
2. For every thing that has no installed version and is not a subject to build (e.g. .../t/*.sql), use it's version in the source tree.
3. For every thing that has no installed version and should be built (e.g. src/interfaces/ecpg/test/connect/*.pgc), build one-time version and use it.

Regarding to ecpg tests it means that we should use installed ecpg, installed libs, installed *.h, and compile src/interfaces/ecpg/test/connect/*.pgc into a temporary binary.

Maybe I miss some use cases, where existing design suits better, but in general I think that the more test coverage (more installed things checked), the better.


Best regards,
------

Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company