[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-build-dev
Subject:    Re: --with-devkit doesn't control nmake
From:       Derek White <derek.white () oracle ! com>
Date:       2016-01-19 22:13:14
Message-ID: 569EB4FA.7070800 () oracle ! com
[Download RAW message or body]

On 1/13/16 1:51 PM, Erik Joelsson wrote:
> For your build to pick up nmake from some other VS installation means 
> you must have that VS installation in your path. Normally, only the 
> devkit bin dirs will be in the path if you start with a clean 
> environment. We have simply not encountered that before, but it is 
> definitely a bug. However, the hotspot build-infra project is 
> currently rewriting the hotspot makefiles (see build-infra/jdk9 forest 
> if you are interested) and we are getting rid of nmake. This project 
> will go into JDK 9 in hopefully not too long a time.
>
> Unless this is causing actual trouble now, we in the build group will 
> be reluctant to spend time on fixing the issue. We would of course 
> welcome contributions from others if someone is willing to do the work.

Unfortunately our devops group by default supplies an "entitlement" 
Windows VM with 3-4 VC++ toolchains on the path. But I think the option 
of removing nmake is the right way to go. It also takes care of the 
issue of how to specify customized make arguments to both the gmake and 
nmake programs we currently use.

Thanks!

  - Derek
>
> /Erik
>
> On 2016-01-08 23:16, Derek White wrote:
>> [This is likely a bug, but thought I'd ask it as a question first].
>>
>> Windows devkits contain an nmake.exe, but the configure and make 
>> scripts do not define and consistently use an NMAKE variable to make 
>> sure the devkit version is used, as many other commands do.
>>
>> I had assumed that my builds were using the nmake.exe from the same 
>> devkit toolchain as the compilers, etc., but in fact I was using 
>> nmake from VS2005, as provided by my company's devops department on 
>> my entitlement machine.
>>
>> I don't believe that actually caused problems in my builds, but it 
>> took a while to confirm it, and could easily cause a problem in the 
>> future.
>>
>> Bug or no bug? Thanks!
>>
>>  - Derek
>

[prev in list] [next in list] [prev in thread] [next in thread]