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
