Project Proposal: Build Infrastructure Changes

Steve Poole spoole at linux.vnet.ibm.com
Tue May 3 09:18:20 UTC 2011


On 30/04/11 00:05, Kelly O'Hair wrote:
>
> On Apr 29, 2011, at 1:31 PM, Steve Poole wrote:
>
>> On 26/04/11 15:54, Kelly O'Hair wrote:
>>>
>>> On Apr 26, 2011, at 12:59 AM, Steve Poole wrote:
>>>
>>>>>>
>>>>>>    * Allow for use of more portable build tools (compilers etc.) where possible
>>>>    Can I add support for alternative JVM's ?
>>>
>>> Seems a bit out of scope to me.
>>>
>> Sorry, it was  a bit of a flippant one liner,  I owe you more details.
>>
>> There are three usecases I see that require the OpenJDK build process 
>> to be modified to accommodate:
>>
>> The first is bootstrapping a build.   I'd like to be able to build 
>> OpenJDK on a new platform without the need for a previous SDK build 
>> to be present.
>> In this usecase it's possible that an simple interpreter based JVM 
>> would be sufficient (ie Zero)   (or even  maybe a cross compiling mode)
>>
>> The second  is  getting OpenJDK to build on a platform where a 
>> hotspot JVM doesn't exist and may never exist.   As you guess I'm 
>> thinking of IBM platforms specifically. I'm don't expect to port 
>> Hotspot to AIX so I need to be able to make the OpenJDK build work 
>> with J9.
>>
>> The third (a variant of the 2nd)  is where another JVM vendor wants 
>> to get OpenJDK working with their JVM - regardless of the 
>> availability of a Hotspot JVM on the target platform.
>>
>> To be clear.  I'm not suggesting that this project step up to 
>> defining the interfaces between JVM and classes.   This is simple 
>> pragmatics. The Hotspot JVM is the starting point for the mould and I 
>> would expect to make J9 (or any new JVM) fit into it as much as 
>> possible.   However there will be changes needed.  These are mostly 
>> simple,  like parameterising  JVM command line options,  to the more 
>> complicated like separating out  JVM intrinsic classes such as 
>> String.java, Object.java,  Thread.java etc so that the right versions 
>> get build and packaged.
>
> I certainly can understand these needs, but it is still seems beyond 
> the initial scope of this project.
> Maybe in a phase 2?

Hmm, maybe doing all of them in one go may be a stretch :-) The 2nd 
usecase is fundamental though to supporting IBM platforms, something you 
mentioned you wanted to do.  Is there any reason why realising that 
usecase is beyond phase 1?


>
> -kto
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20110503/ce3456b7/attachment.htm>


More information about the build-dev mailing list