RFR: 7181175 Enable hotspot builds on Windows with MinGW/MSYS
tim.bell at oracle.com
Wed Jul 4 06:38:47 UTC 2012
Additional comments inline:
On 07/03/12 00:40, Volker Simonis wrote:
> 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:
>>> 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
>>> A Windows-only JPRT build/test run was successful: job
>> 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:
>>> Bug fix #7152336  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
> "..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.
> 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.
>>> Thanks in advance-
>>> Tim Bell
More information about the build-dev