My original reply does not seem to have made it to build-dev.
I've updated the webrev again to accommodate openjdk builds that set
REDUCED_JRE and/or REDUCED_HEADLESS_JRE. The main changes are:
- don't try to run freetypecheck when cross-compiling
- delete build of freetypecheck from make/tools/Makefile as Sanity.gmk
will build if needed
- for OpenJDK builds leave the JRE fonts alone (the Lucida fonts that we
don't delete are not part of OpenJDK)
David
-----
David Holmes said the following on 03/09/11 09:33:
Andrew,
Dr Andrew John Hughes said the following on 03/09/11 03:24:
On 10:51 Tue 08 Mar , David Holmes wrote:
Just to clarify for people, BUILD_CLIENT_ONLY refers to building
the client VM only.
Some of these variables should be documented in the top level
README-builds.html file, but that
can be done under a separate CR if necessary.
What happens if there is no client VM e.g. x86_64?
If you are not building a client-only configuration then you should
not set BUILD_CLIENT_ONLY. It's main purpose is to not attempt to
copy lib/<arch>/server/*.so files into the JRE/JDK image when they
don't exist.
But what if someone does? Will the sanity check not catch this?
If you specify BUILD_CLIENT_ONLY then you are telling the build system
to not try and copy/define anything pertaining to the server VM. Whether
or not you've built a server VM in such circumstances is irrelevant and
certainly not a fatal error requiring a sanity check (I'm not even sure
the sanity check can tell).
I can certainly refactor into general flags, however applying those
flags to all parts of the JDK build process that might want to use
them is out-of-scope for what I am trying to achieve here (I just
won't have time to do this and go through a myriad of builds and test
runs). I'd also prefer not to create multiple changesets, which
implies multiple CRs. I can't easily test these things in isolation,
and individual changesets would require complete build/test cycles
that I again do not have time to perform.
I can see the issue with it taking more time, but committing the patch
in its
current form is unfair on others who now have a more convoluted build
system
to deal with (and it's already bad to start with) and no gain from the
patch.
The intent is that anyone not setting any of the "new" build variables
will be unaffected by these changes. They may benefit from the basic
cross-compilation support, and the ability to produce a client-only
JRE/JDK.
Does the revised structure improve things from your perspective?
Does your employer not allocate sufficient time to do the best work
you can
on such changes?
We all have schedules and deadlines to meet. These changes have been
percolating for sometime now and my window for getting them out is quite
narrow. My problem is exacerbated by the fact that JDK7 is a fast moving
target at the moment and so I'm continually having to merge changes,
update things that break my build, and go through the rebuild cycle
again to verify things. Hence I want to try and push things through in
one hit (in actuality several other changes that are more stand-alone
have already been broken off from this).
Has this been tested on an OpenJDK build at all? It also seems to
create a fonts.dir file with fonts
that aren't part of OpenJDK.
No, not OpenJDK. I have done a regular JDK build, but not OpenJDK.
And I have not attempted to test things like BUILD_CLIENT_ONLY
outside of a JAVASE_EMBEDDED build.
With regard to the fonts, my understanding is that we simply define a
subset of the fonts used in the regular JDK. I have no idea how such
fonts get shipped nor whether they are part of the OpenJDK or only
Oracle's JDK.
An OpenJDK build definitely needs to be performed before this is
committed,
as I think it may break the build or, at the very least, create
references
to non-existent fonts.
I have no problem doing an OpenJDK build on this, I will attempt an
OpenJDK build that uses all of the new flags except for actually
defining JAVASE_EMBEDDED. That said I still don't understand the font
issue. We delete a bunch of fonts and then create a fonts.dir file that
refers to the set of fonts we didn't delete. Are these fonts not present
in an OpenJDK build? I can make that part conditional on it not being an
OpenJDK build if that is the case.
Thanks again for the feedback.
David
Thanks again,
David
-kto
On Mar 7, 2011, at 2:14 AM, David Holmes wrote:
http://cr.openjdk.java.net/~dholmes/7025066/webrev/
The SE-Embedded product is a combination of open and closed
sources. To allow SE-Embedded to be built from standard OpenJDK
sources we need to apply a number of changes to the SE 7 build
system:
- support for building the hotspot client compiler only (hotspot
already supports this, this is the JDK side of things)
- support for doing cross-compilation (Linux only)
- minimal support for ARM/PPC architectures in the open code that
currently only knows about x86 and sparc
- SE-Embedded specific build settings and targets (specifically
the headful and headless reduced JRE images)
---
These changes are obviously primarily for Oracle's benefit, but
some aspects may be use of externally as well. The hope is that
these changes won't have an adverse affect on any downstream
OpenJDK builders, but until I get feedback on that I won't know.
Thanks,
David Holmes
SE Embedded Team
