Preliminary request for review: 7025066 Build system changes to support SE Embedded integration

[Dr Andrew John Hughes]

On 22:09 Wed 09 Mar     , David Holmes wrote:
> 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:
> 

Another problem with these webrevs is that you don't know if someone
changed it.  Neither do you then have any history of what went before.

> - don't try to run freetypecheck when cross-compiling
> - delete build of freetypecheck from make/tools/Makefile as Sanity.gmk 
> will build if needed

These sound sensible changes.  We've run into similar issues with the
freetype test in IcedTea too.

> - for OpenJDK builds leave the JRE fonts alone (the Lucida fonts that we 
> don't delete are not part of OpenJDK)

Ah, that solves what I just explained in my last reply.

> 
> 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
> >>>>>>
> >>
> > 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37