RFR: 7181175 Enable hotspot builds on Windows with MinGW/MSYS

[Tim Bell]

Additional comments inline:

On 07/03/12 00:40, Volker Simonis wrote:
> Hi,
>
> please see my comments inline..
>
> On Tue, Jul 3, 2012 at 7:07 AM, David Holmes<david.holmes at oracle.com>  wrote:
>> Hi Tim,
>>
>>
>> On 3/07/2012 1:52 PM, Tim Bell wrote:
>>> All-
>>>
>>> This is the hotspot-only portion of the changes to allow building on
>>> Windows with any of MKS, Cygwin, or MinGW/MSYS as the 'Unix-like' shell
>>> environment:
>>>
>>> http://cr.openjdk.java.net/~tbell/7181175/webrev.00/
>>>
>>> A Windows-only JPRT build/test run was successful: job
>>> 2012-07-02-230003.tbell.hotspot
>> Did you try both -release 7 and -release 8? There are additional build
>> platforms for 8 (Windows versions) though both use VS2010.

Both of these jobs were successful:

Release:      jdk7u6
Release:      jdk8


>>> Bug fix #7152336 [1] will be used to update the other repos after these
>>> changes are in hotspot.
>>>
>>> I'd like a quick review from some HS runtime members, and then I will
>> I'm concerned by a few changes in sa.make.
>>
>> First all of the changes from \ to /. I can't help but think this was left
>> at \ for a reason. Do we know this works on all build platforms? Further we
>> still use \ in other makefiles so surely they all need to be fixed - eg see
>> adlc.make (the existing inconsistency here is surprising and disturbing)
> I think the '\' are a leftover from the times when Windows could not
> handle forward slashes in path names (Win95/98 ??). As far as I can
> tell, that's no a problem any more. For the initial submission I've
> tested the change with MinGW/MSYS, Cygwin and MKS on WindowsXP and
> Windows Server 2003 and Windows 7 and didn't find any problems.
>
> As I explained in the initial webrev
> (http://cr.openjdk.java.net/~simonis/MinGW_MSYS_hotspot.v1):
>
> "..The patch mainly replaces forward slash style options (e.g. /NOLOG)
> for calls to Windows programs with their corresponding dash form (e.g
> -NOLOG) and backslash path separators with forward path separators (or
> prevents the replacement of forward path separators with backslash
> path separators if this was not necessary).
>
> Note that this change is minimal in the sense that I only did "just
> enough" changes to be able to build on Windows with either one of the
> three Unix emulation environments (MKS, Cygwin, MinGW/MSYS).

Once nmake takes over during the hotspot build, the use of legacy '\' 
works fine, as before.

As Volker writes, that is why only a fraction of the makefiles were 
touched.  The changes are related to the transition of control between 
gmake running in some shell and nmake.

The only Windows program I have encountered so far that will not 
tolerate '/' instead of '\' in a path (and the corresponding use of '-' 
instead of '/' to introduce an option) is the ancient DOS "copy" 
command, but this is used much later in the build; not in hotspot.

> Particularly I haven't done the above changes in the nmake make files
> although this would have been possible. I'm very much in favor of
> completely removing the special nmake make files and do the complete
> build with GNU make. Besides the fact that this unifies the makefiles
> and removes yet another dependency from the build, this will also
> allow to take advantage of parallel HotSpot makes as this is currently
> done under Linux and which is much faster on recent multi-core
> hardware than the nmake batch build mode. As noted, these improvements
> are left for a future change.."

Correct - that is a project to consider, but currently outside the scope 
of the MinGW/MSYS work.

> But I agree, that at least on "file-level" the changes should be
> consistent. For sa.make (which is a nmake file but for some reason I
> had to touch it so I did all the mentioned changes right away), this
> would mean that for the following lines:
>
>    98 !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1"
>    99 SA_CFLAGS = $(SA_CFLAGS) /ZI
>   100 !endif
>   101 !endif
>   102 !if "$(MT)" != ""
>   103 SA_LD_FLAGS = /manifest $(SA_LD_FLAGS)
>   104 !endif
>
> the "/"-Options should be replaced by "-"-Options. (Lines 98 trough
> 101 have not been there when I did the initial change and I somehow
> must have missed the "old-style" option in line 103).

I have incorporated these changes to sa.make...

> Second this seems wrong:
>
>   "$(COMPILE_RMIC)" -classpath ...
>
> If COMPILE_RMIC is re-defined as "rmic<some-arg>" then the above will fail
> to execute. Plus didn't you already handle the spaces-in-paths problem in
> rules.make when you defined COMPILE_RMIC?

I see your point - rather than change this line in sa.make, modify the 
changes in rules.make.

Unfortunately, I see this works in the JPRT jobs I submitted today, but 
falls apart for no reason I understand in my laptop build environment.  
Very frustrating, but I will have to get back to you on this issue.  It 
is quite possible that my laptop is a mess at the moment.

I wanted to reply on the other items, and to say that this is not some 
crazy idea we just woke up with - we (build-infra-dev at openjdk.java.net) 
seriously want to work towards doing jdk8 builds using Windows 7 and 
MinGW/MSYS for both 32 and 64 bit builds, end-to-end.

Thanks-

Tim

> Third the changing of the compiler options from /opt to -opt. In
> compile.make we use /opt for everything. So either your change is
> unnecessary, or there seems to be a lot of other changes needed. ???
>
> See comments above..
>
>>> need to ask for a volunteer to push the change in (unless I can do that
>>> myself by submitting to JPRT... glad to do it if it is OK).
>> Sorry but you don't have Committer status, nor Author status for the HSX
>> project, so will need a sponsor for this contribution.
>>
>> Cheers,
>> David
>> -----
>>
>>
>>> Thanks in advance-
>>>
>>> Tim Bell
>>>
>>>
>>> [1]http://cr.openjdk.java.net/~tbell/7152336/webrev.02/
>>>