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

[David Holmes]

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:

- don't try to run freetypecheck when cross-compiling
- delete build of freetypecheck from make/tools/Makefile as Sanity.gmk 
will build if needed
- for OpenJDK builds leave the JRE fonts alone (the Lucida fonts that we 
don't delete are not part of OpenJDK)

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