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

On Sat, Jul 04, 2015 at 11:26:07AM +0900, Michael Paquier wrote:
> 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.

At several seconds and >1000 files created, an extra temporary installation is
not cheap. (Indeed, that expense motivated commit dcae5fa.) The GNU make
build system never creates a temporary installation for just psql. Insurance
is not valuable in this area. If someone modifies a suite to need an
additional binary without updating the test harness to furnish that binary,
the buildfarm will catch the mistake.

MSVC build system semantics should mimic the GNU make build system, not
innovate. In released versions, vcregress.pl departs from that by using the
build tree psql instead of an installed psql. In 9.5, it will use psql from a
temporary installation. Where's the improvement in that? It replaced one
inconsistency with another.

> 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 :)

I don't wish to. I was content with released-branch vcregress.pl semantics.