On 09:33 Wed 09 Mar , David Holmes wrote: > 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'm not saying it should define anything with respect to the server VM, merely that x86_64 (and possibly other platforms in future) and BUILD_CLIENT_ONLY are incompatible and the sanity check could catch this with an arch check. > >> 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. > It also means that someone will need to regularly maintain the settings created by these new variables. I think it's more likely that this work would be tested and maintained by others if individual options were available without requesting an entirely different build. This is especially the case with JAVASE_EMBEDDED as I'm not sure what that even equates to (except some future Oracle product). > Does the revised structure improve things from your perspective? > I'm not sure what 'revised structure' you're referring to. > > 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). > Yes, we're all subject to the fast development pace of OpenJDK7, but I guess that will start to slow down when OpenJDK8 forks off. I would have thought committing stuff in small chunks was more amenable to this situation, as there is less chance of something disrupting it while you're working on it and you can get it in the codebase quicker. > >>> 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. > There are no fonts in the OpenJDK codebase. You can verify this with a quick run of find. If I recall correctly, the patch does this font addition in JAVASE_EMBEDDED mode (it's really hard to comment on a patch when it's not in the mail itself) so you definitely need to test that with OpenJDK. To be honest, it seems odd to be even having to ask for someone to test the default build before submitting a patch... > Thanks again for the feedback. > Thanks for the patch. If I'm critical, it's because a few of these features would be nice to have generally available and this patch will actually make them harder to add, as supporting them generally may break your JAVASE_EMBEDDED build. > 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
