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