Hello Andrew,
Thanks for the feedback! Adding in my view of things below.
On 2013-03-13 17:16, Andrew Hughes wrote:
I've just got my first build out of the new system using the main jdk8/jdk8
tree (b80) and
so thought it was worth giving some feedback on the problems encountered and
issues
with the end result:
1. It took some time to work out how to get back to the usual 'noisy' build as
the
default seems to subdue all the useful output. VERBOSE=true broke the build
when
it tried to use 'true' as a Makefile target. It turns out the solution is the
rather
non-obvious VERBOSE= . Could we not have this documented somewhere and perhaps
have
verbosity as a configure option? After grepping around, it's not very obvious
to me
where it gets set.
As already pointed out, the preferred way is to use
LOG=warn/info/debug/trace, where "debug" best matches what the old build
did. I don't recommend trace for normal use. The default level tries to
keep the user informed about what is happening without information
overload. It also makes warning messages stand out more in the hope that
it annoys someone enough to go fix them. I agree that adding a configure
option for changing the default is a good idea and would welcome such a
patch. Internally we encourage using "debug" for nightly/remote builds.
The build output is also saved to build.log in the configure directory
as David said.
2. One of the javac calls in the jdk tree fails with:
/home/andrew/projects/openjdk/upstream/jdk8/jdk/src/share/classes/javax/swing/JSpinner.java:43:
error: package sun.util.locale.provider does not exist
/home/andrew/projects/openjdk/upstream/jdk8/jdk/src/share/classes/javax/swing/JSpinner.java:44:
error: package sun.util.locale.provider does not exist
/home/andrew/projects/openjdk/upstream/jdk8/jdk/src/share/classes/javax/swing/JSpinner.java:45:
error: package sun.util.locale.provider does not exist
This package is in the jdk8 tree but not in the build JDK (7). Oddly, the build
continues despite this error and the final rt.jar does include JSpinner.
It's actually not javac, but probably javadoc as David said, and is part
of java source generation. I'm guessing it's the swing beans (dt.jar)
that previously were generated at image creation time. It seems harmless
though, but perhaps it needs to be investigated.
3. -Werror is set for the SCTP native code causing the build to fail:
Lots of stuff like:
/home/andrew/projects/openjdk/upstream/jdk8/jdk/src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c:88:24:
error: unused parameter 'klass' [-Werror=unused-parameter]
as -Werror is passed and -Wno-unused doesn't seem to turn these off.
SCTP_WERROR=
worked around it (perhaps this should at least be WARNINGS_ARE_ERRORS to match
HotSpot?)
Do we have a preferred way to fix these errors? I know about __unused__ but I
believe this
is GCC-specific and I wouldn't want to break the build on other platforms
(Solaris, MacOS X, BSD).
This I have not noticed. Is it specific to some GCC version?
4. It's odd that the default 'make' no longer means 'make all' and 'make' on
its own doesn't produce
a JDK image to use. This will be confusing for newcomers who miss that
important 'all' word or people
like me who go by the usual presumption that the default argument to make is
'all', but appears to have
been subverted here.
I can agree that it's a bit odd. It was done this way early on to reduce
build times for the average developer who usually isn't interested in
images and certainly not docs. For openjdk, we have "default" which
translates to "jdk" and "all" which translates to "images docs". One
could argue that the developer wanting to save time could type "make
jdk" instead, but then, the developer wanting save time probably just
wants to type "make".
The root Makefile is still the old build, but the first thing it does is
calling NewMakefile.gmk unless NEWBUILD=false is set. When we finally
remove the old build system, NewMakefile.gmk will replace Makefile in
the root.
5. The final image produces:
openjdk version "1.8.0-internal"
from -version. I can't remember whether or not the internal was there before
and we suppressed it in IcedTea,
but we've definitely always had 'java version' and not having this will break
numerous applications (possibly
including the JDK build, as I know at least the old one used to check the
version).
AFAIK this is the same with the old build. We have certainly not tried
to change it. If you need additional configure logic to change or remove
that string that isn't already there, that shouldn't be a problem.
/Erik
