PGI: Load pgort<ver>.dll from the VS native tools env; do not `install` it (#12581)
authorDaniel Podder <dpodder@gmail.com>
Thu, 14 Sep 2017 17:35:42 +0000 (10:35 -0700)
committerGitHub <noreply@github.com>
Thu, 14 Sep 2017 17:35:42 +0000 (10:35 -0700)
commit6ac4c997b65d45a460368463f342477326cecd1f
tree662dd64841d1774fa53ad697a2fa83dac949820a
parentb5bcc13876b31e6ab83c58e7bf362410124d681f
PGI: Load pgort<ver>.dll from the VS native tools env; do not `install` it (#12581)

On Windows, PGO instrumented builds (build.cmd release <arch>
pgoinstrument) introduce a runtime dependency on pgort<ver>.dll for
instrumented binaries. This DLL is distributed alongside the C++
compiler, and is made available via the native tools environment that
ships with Visual Studio.

Previously, we were using cmake to find and "install" this binary
alongside the product when doing an instrumented build, so that the
resulting bin\Product drop is free of any added external dependencies.
However, this approach is fragile, and despite a best effort to make the
implementation work across multiple VS releases, it already broke with
VS 2017.

To fix support for pgoinstrument on VS 2017, and to harden the
implementation for future releases of VS, I'm removing the custom cmake
install logic for the pgort DLL. Instead, we fall back to the officially
supported method: load the correct (native tools) environment before
invoking any command that uses an instrumented binary. This happens in
one place in the build today--loading the JIT to crossgen
System.Private.CoreLib.dll.

Note that there's still an existing CLI/Setup bug that requires copying
the pgort DLL. We're now doing it from within build.cmd, which is not
nearly as fragile for this as cmake is. The workaround is also isolated,
so when the referenced issue is fixed, the workaround (as documented)
can simply be removed.

Fixes #12347.
build.cmd
pgosupport.cmake