Re: contribcheck and modulescheck of MSVC's vcregress.pl cannot work independently

On Sat, Jul 4, 2015 at 10:37 AM, Noah Misch wrote:
> This worked around defects in commit dcae5fa: "check", "ecpgcheck" and
> "upgradecheck" are the only test targets properly requiring an installation.
> The others are installcheck-style targets that need just a couple of binaries
> from the build tree; they should be using --bindir=<relpath>/$Config/psql like
> installcheck itself.

Well, I disagree here. For one, that's a cheap insurance regarding the
fact that a test set may need more than psql as a binary and it makes
all the tests use the same consistent way of doing. Also, if we would
want to have a real installcheck mode, what we should use is not the
path to what has been built but the path to the installation that the
Postgres instance needed is using. Now if you want to fix it if you
fix that's incorrect I won't complain about that :)

Hence, perhaps that a complete answer is to actually gulp completely the bullet:
- Make installcheck look for pg_config in PATH, and use it to
determine where are the builds. Give as well the option for user to
define a custom path at will.
- Switch all the targets to create by themselves a Postgres instance
similarly to the normal Make (I have always found troublesome that it
is necessary to install contrib/ when wanting to test them, and to
start a Postgres service).
- Create an allcheck target, that will kick all the targets, except
installcheck.
- And an allinstallcheck target that will use an existing instance for
all the targets, with installcheck.
If we can give up on installcheck, I think that we should as well be
able to pass an option "use the existing instance" using an option in
vcregress.pl.
I don't think that this is more than a couple of hours of work, and
will be happy to send a patch for 9.6 if people like those ideas.
Regards,
--
Michael