RFR: JDK-8035725 Must keep microsoft VS_PATH on PATH after toolchain detection

[Bradford Wetmore]

On 2/25/2014 6:13 AM, Kumar Srinivasan wrote:
> Never mind it is indeed the same issue, I found the bug filed by Brad on
> this.

Just FYI, this morning's push addressed my problem.

Brad


>
> Thanks
> Kumar
>
> On 2/25/2014 6:11 AM, Kumar Srinivasan wrote:
>> Hello Magnus,
>>
>> On our team CI server we are seeing these failures on Windows,
>> are they related to this fix ? Or is this something else ?
>> Message snippet inlined below.
>>
>>
>> Thanks
>> Kumar
>>
>> checking Checking for install src... found
>> checking for ant... /devtools/ant-1.7.1/bin/ant
>> checking for JUnit... no, deploy tests cannot be run
>> checking for mozilla headers... no, needed for deploy, set
>> --with-mozilla-headers=/path/to/mozilla-headers
>> checking for wix... no, needed for installer, set --with-wix=/path/to/wix
>> checking for wscript... /cygdrive/c/Windows/system32/wscript
>> checking for cscript... /cygdrive/c/Windows/system32/cscript
>> checking for msicert... no
>> cygpath: can't convert empty path
>> cygpath: can't convert empty path
>> configure: The path of MSICERT, which resolves as "", is not found.
>> configure: error: Cannot locate the the path of MSICERT
>> configure exiting with result code 1
>> Archiving artifacts
>>
>>
>> On 2/25/2014 3:32 AM, Magnus Ihse Bursie wrote:
>>> After the toolchain rewrite, we could fail in various ways on Windows
>>> builds, e.g. like this:
>>> configure: Rewriting OBJDUMP to "/usr/bin/objdump"
>>> configure: error: Target CPU mismatch. We are building for x86 but CL
>>> is for "directory"; expected "80x86".
>>> configure exiting with result code 1
>>>
>>> The reason for this is that we save the PATH, set it to the Visual
>>> Studio special PATH (and other special PATH tricks on other
>>> platforms), do the toolchain checking, and then restore the PATH.
>>>
>>> However, on Windows, the compiler (for x86 at least) needs to have
>>> that special PATH at all times, since it is used for dll resolution.
>>> So without that path, subsequent calls to the compiler will fail.
>>>
>>> This fix makes sure we set up the Visual Studio path "permanently"
>>> for the rest of the configure run, so that we can always run the
>>> compiler after it has been detected.
>>>
>>> This was the behavior before the toolchain cleanup. And, if you're
>>> curious, we do setup the proper PATH in spec.gmk so that we can run
>>> the compiler correctly when building. :-)
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8035725
>>> WebRev:
>>> http://cr.openjdk.java.net/~ihse/JDK-8035725-keep-VS_PATH-after-toolchain-detection/webrev.01
>>>
>>>
>>
>