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
