Preliminary request for review: 7025066 Build system changes to support SE Embedded integration
Dr Andrew John Hughes
ahughes at redhat.com
Fri Mar 11 01:02:12 UTC 2011
On 17:35 Thu 10 Mar , David Holmes wrote:
> Dr Andrew John Hughes said the following on 03/10/11 10:26:
> > 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.
>
> Sorry, this was just a preliminary RFR so I didn't set up the webrev
> versioning.
>
My issue was more a personal distaste for webrevs than anything you did
wrong. I just find it much easier if everything is in the e-mail and
can be commented on inline rather than on some website that has to be
loaded up in a separate window and can change or even disappear. It's
especially true for big patches like this, where you really need to
break the patch down in the mail.
> I'm looking into a new structure where the JAVASE_EMBEDDED stuff is
> factored out into Defs-embedded.gmk and Release-embedded.gmk. This will
> relegate the reduced-jre targets to being relevant to embedded only and
> anyone not interested just doesn't look in those files.
>
My fear is not so much Makefile clutter as that untested options can bit rot.
People make modifications in one area and these unused options are missed.
That's actually more likely if you squirrel it away in a separate file.
> I'm also looking at breaking this into three components
> - build-client-only (if I can't somehow hide that in the embedded bits)
> - basic cross compilation support
> - SE-Embedded support (including things like COMPRESS_JARS and
> ZIP_CAN_USE_MMAP)
>
> Stay tuned.
>
> Thanks again for the feedback.
>
Thanks.
> David
>
> >> - 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
More information about the build-dev
mailing list