Those changes look quite familiar, but more comprehensive. Thanks. I will give them a try in a minute, after I see how far I get with the 2010 DirectX SDK.
That one has the desirable property of not messing up %PATH%. I suspect, based on others' experience, that we'll want need to adjust how we deal with DirectX if we want to use the not-2004 version (I didn't seen any occurrence of "directx" in your patch). David On 2013-05-22, at 8:44 PM, Tim Bell <tim.b...@oracle.com> wrote: > We are in the process of evaluating build tool selections for JDK8. > > For Windows, Anthony Petrov started the work and supplied a patch [1], plus > more changes for hotspot. > > I have successfully completed OpenJDK builds of the JDK8 build forest using > Visual Studio 2012. The runtime .dll selection that Kelly is referring to > takes place in toolchain_windows.m4. > > The binaries produced by my builds passed a few basic checks like 'java > -version' and ran the JVM98 benchmark for a few minutes. Much more testing > remains to be done. > > Here is a pointer to the source changes I needed to make, so far: > > http://cr.openjdk.java.net/~tbell/VS2012/webrev.00/ > > You will need to run 'bash common/autoconf/autoconf.sh' after applying the > patch from the webrev. > > It has also been reported that the free VS2012 'Express' edition does not > include the 64-bit compiler, so you will be able to build 32-bit only. I > have not verified that. > > Tim > > [1] http://hg.openjdk.java.net/jdk8/awt/rev/dd1a80efa7cf > > > On 05/22/13 04:27 PM, David Chase wrote: >> I hope I'm trying to solve a simpler problem, which is just a build, as if I >> were someone outside Oracle playing with Openjdk. I assume my problems are >> a subset of the release problem. >> >> David >> >> On 2013-05-22, at 6:53 PM, Kelly O'Hair <kellyoh...@gmail.com> wrote: >> >>> Windows VS compilers are a pain. Each release has it's own unique runtime >>> DLLs, which we must deliver with the JDK, so the build process has to know >>> what that DLL is named, where it is located, and copy it into various >>> places. >>> >>> DLLs created by a newer VS will not like the older VS runtime DLLs. >>> >>> To make a long story short, changing VS compilers is a royal pain, and not >>> trivial. >>> This is why we only recommend VS2010. >>> >>> I'm not saying it cannot be done, I'm just saying you should have plenty of >>> liquor available when you do it. :^( >>> >>> -kto
