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

[David Holmes]

Andrew,

Many thanks for the feedback:

Dr Andrew John Hughes said the following on 03/08/11 04:30:
> On 09:39 Mon 07 Mar     , Kelly O'Hair wrote:
> 
> General comments:
> 
> * Could this not be broken up into smaller changesets to make it easier to review and catch regressions?

In theory probably, in practice, not really. Please see below.

> * There seem to be some whitespace changes that shouldn't be there.
> 
> e.g.
> 
> -	sane-msvcrt_path \
> +	sane-msvcrt_path \

This will all be double-checked before the push.

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

> I think if this patch introduces it, the documentation should be part of this patch.

Definitely.

>> The Library.gmk file seems like it is just a leftover debugging echo?

This was Kelly's comment, but yes it is a _very_ useful debugging echo 
that I suggest leaving in.

>> The Release.gmk file needs  a major overhaul. :^(  I'm wondering if the various things being added here could
>> have their own separate functionality flags, rather than JAVASE_EMBEDDED,  have COMPRESS_JARS=true/false,
>> REDUCED_JRE=true/false, then have one place where JAVASE_EMBEDDED turns on what it wants?
> 
> Strongly agree with this.  It would make more sense to have these sort
> of changes introduced by separate changesets and then have this change
> set them for the JAVASE_EMBEDDED build.  In particular, COMPRESS_JARS
> was something I had planned on fixing.  To Kelly's list, I'd add
> BUILD_ALSA and LIBZIP_CAN_USE_MMAP (mentioned below).  This would make
> this work far more generally useful than it is at present.

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.

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

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