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

[David Holmes]

Tim, Volker,

Thanks for the comments and explanations about the transition from gmake 
to nmake - very confusing.

That just leaves the COMPILE_RMIC issue to resolve.

Thanks,
David

On 4/07/2012 4:38 PM, Tim Bell wrote:
> 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/
>>>>
>
>