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.hol...@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-...@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/
