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

[David Holmes]

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