Hi Steve, The initial proposal was aimed to address issues in the existing build process that we felt could be improved in the short term. The idea was to share some ideas and experiments we have done and invite discussion on these approaches. Starting the project will give us a set of repos to do these experiments.
The list that Kelly presented could be done in one or two short projects. We want to do this in a relatively short time, since these could potentially affect almost every makefile and build script. We want to minimize the impact that it will have on other projects, for example porting. If the use cases you present can be done in the same time as the list in the proposal, we might want to consider them for this project. If not we should be careful to not make choices that will make it difficult to support these use cases as possible next steps. This will be clearer when we discuss the approaches to solving the project goals. Mohan On May 3, 2011, at 11:18 AM, Steve Poole wrote: > 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 >> >
