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

[David Holmes]

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.

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.

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.

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