On Thu, Mar 8, 2012 at 8:00 PM, Kelly O'Hair <kelly.oh...@oracle.com> wrote:
>
> On Mar 8, 2012, at 10:00 AM, Volker Simonis wrote:
>
>> This thread will probably never end (Windows 2046 :)
>>
>> So I did more test......
>>
>> - I wanted to compare with MKS and the first thing I hit on was a bug
>> in MKS's 9.4 version
>> of cpio ("CFS# 32408--- cpio can not handle files which are
>> ReadOnly"). And it's expensive
>> and installation and license handling is PITA if you use several
>> virtual machiines..
>
> MKS 9.4 is seriously broken for us. I use 9.0p3 or 9.0p4. I filed a ticket
> with MKS on this issue months ago and
> have never heard back from them, and we have a support contract with them
> too. :^(
>
>>
>> - Still couldn't find the reason why the build hangs with Cygwin 1.7.10
>
> that's a new one for me.
>
> When both MKS and CYGWIN are installed on the same system it can be tricky.
> After I install MKS I usually go in and take MKS out of the default PATH, and
> change
> SHELL to be just /usr/bin/sh (which appears to be more of a universal keyword
> than a path to a shell).
> Then I go shut down and disable all MKS services.
> Then when I want an MKS shell started up, I have some hacky PATH setting and
> exec of
> the MKS shell. I could send you the formula if you would like.
>
> I've just kept wishing MKS could go away for us... someday... And you have
> provide a light at the end of the tunnel. ;^) Thanks!
>
>>
>> Finally I decided to try something new - MinGW/MSYS.
>>
>> And indeed - it worked, it's nearly as fast as MKS, it can use the
>> default make which comes
>> with the MinGW/Installation. Read the glory details at:
>>
>> http://mail.openjdk.java.net/pipermail/build-dev/2012-March/005729.html
>>
>> Please feel free to test, review and (hopfully) submit it.
>>
>> The changes are intentionally against the old, "traditional" build system to
>> fix
>> the mentioned Cygwin problems and simplify the Windows build just now.
>>
>> As next steps I see the following points:
>> - integrate MinGW/MSYS with the new build system
>> - completely remove nmake from the HotSpot build and use prallel GNU make
>> like on Linux (I know this works and that it's faster - just have to
>> build a OpenJDK patch)
>>
>> Any comments?
>
> Fantastic stuff. I'll work on getting it in place.
>
> On replacing NMAKE, I agree with you however, I think NMAKE may be in cahoots
> with the
> VS compiler with regards to licensing checks or pre-compiled headers, the
> build is pretty fast.
> In my crude attempts in the past, I could never get anywhere close to the
> NMAKE build speed.
> Never completely understood why. :^(
>
I don't understand the licensing checks problem you mention? Do you
mean 'cl' can only be called from nmake?
I havn't seen this problem, although our internal build without
'nmake' I was mentioning runs with the commercial
and not the Express version of MSVS.
For the precompiled headers issue we found a solution. I'll just have
to port it to the OpenJDK.
> -kto
>
>
>>
>> Volker
>>
>> On Wed, Feb 15, 2012 at 1:10 PM, Fredrik Öhrström
>> <fredrik.ohrst...@oracle.com> wrote:
>>> ----- kelly.oh...@oracle.com skrev:
>>>
>>>> So I'm with you on the stat() theory, makes a great deal of sense.
>>>
>>> The stat theory is very interesting, but it is unclear to me if it explains
>>> all of the problem.
>>>
>>> I setup a quadruple boot x86_64 machine with 4GB of ram and 4 cores:
>>> Winxp 32bit
>>> Win7 64bit
>>> Solaris 64bit
>>> Ubuntu 64bit
>>>
>>> And tested the build times on the different OS:es.
>>>
>>> Ubuntu Fastest by far.
>>>
>>> Solaris, slower, but this is only because of bad CC performance.
>>>
>>> Winxp, even slower but still ok.
>>>
>>> Win7, ridiculously slow. The configure script prints one line per second!
>>>
>>> Clearly, just running a bash script in cygwin/win7/64bit is problematic.
>>> If we get 10% speedup from dash, then that is not going to help because
>>> the slowdown is a factor 10.
>>>
>>> Could someone try out the difference between a 32bit win7 clean install and
>>> a 64 bit win7 clean install when running the latest cygwin and just the
>>> build-infra/jdk8/common/autoconf/configure script?
>>>
>>> (My patience for installing many OSes into the same box, just ran out. And
>>> virtualization
>>> testing can give a hint, but cannot be entirely trusted.)
>>>
>>> //Fredrik
>
