On 03/05/11 17:05, Kelly O'Hair wrote:
On May 3, 2011, at 2: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 mo
On May 3, 2011, at 3:40 PM, Mike Swingler wrote:
>>
>> I'd like to make that a general rule:
>>
>> #1 Do not run tests as part of the build process
>>
>> :^)
>>
>> -kto
>
> Agreed. Can this be done within the JDK7 timeframe?
That will be tricky. JDK7 changes are now restricted, and I doub
On May 3, 2011, at 3:31 PM, Kelly O'Hair wrote:
> On May 3, 2011, at 2:08 PM, Dmitry Samersoff wrote:
>
>> Generally I agree that gamma launcher should be in hotspot test but minimal
>> "smoke" test at the end of the build is quite useful. The build system not
>> always handle correctly increme
On May 3, 2011, at 2:08 PM, Dmitry Samersoff wrote:
> Generally I agree that gamma launcher should be in hotspot test but minimal
> "smoke" test at the end of the build is quite useful. The build system not
> always handle correctly incremental build and Queens test usually catch it at
> the e
On 05/03/2011 04:13 PM, Mike Swingler wrote:
On May 3, 2011, at 11:27 AM, Kelly O'Hair wrote:
On May 3, 2011, at 10:16 AM, Keith McGuigan wrote:
The number of issues with that gamma/Queens makefile logic is too
high, and it's not something we ship anyway. In my opinion, we
should be restrictin
On 2011-05-03 22:27, Kelly O'Hair wrote:
No doubt it's been useful, but seriously, you just built a hotspot for jdk7,
with a completely different
C++ compiler, and a different C++ runtime dependency, and you plop it down into
a jdk6 image (that
was built with a different C++ compiler, and maybe
On May 3, 2011, at 4:26 PM, Fredrik Öhrström wrote:
No doubt it's been useful, but seriously, you just built a hotspot
for jdk7, with a completely
different
C++ compiler, and a different C++ runtime dependency, and you plop
it down into a jdk6 image (that
was built with a different C++ comp
>> No doubt it's been useful, but seriously, you just built a hotspot for jdk7,
>> with a completely
different
>> C++ compiler, and a different C++ runtime dependency, and you plop it down
>> into a jdk6 image (that
>> was built with a different C++ compiler, and maybe using a different C++
>> r
On May 3, 2011, at 11:27 AM, Kelly O'Hair wrote:
> On May 3, 2011, at 10:16 AM, Keith McGuigan wrote:
>
>> On May 3, 2011, at 12:05 PM, Kelly O'Hair wrote:
>>
>>> I was going to say that building hotspot does NOT require a Boot JDK to
>>> build, but I would be wrong, it does,
>>> but I agree, i
On May 3, 2011, at 10:16 AM, Keith McGuigan wrote:
>
> On May 3, 2011, at 12:05 PM, Kelly O'Hair wrote:
>
>> I was going to say that building hotspot does NOT require a Boot JDK to
>> build, but I would be wrong, it does,
>> but I agree, it probably should not. As I recall, there is some XML
On May 3, 2011, at 12:05 PM, Kelly O'Hair wrote:
I was going to say that building hotspot does NOT require a Boot JDK
to build, but I would be wrong, it does,
but I agree, it probably should not. As I recall, there is some XML
processing, the stupid gamma launcher Queens use,
Whoops... lit
On May 3, 2011, at 2: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
Timeframes... Humm...
Initially I would like to start with a set of jdk7 repositories, go as far as
we can with that, hopefully
show some major improvements in overall build time, then set it aside for
potential inclusion into jdk7u2
(that would require lots of verifications that the end resu
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
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 alternat
Hey Kelly,
One thing that might be useful is to understand the kind of timeframe you
are thinking about for this project?
/GES
On 29 apr 2011, at 16.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 A
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'
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 line
On Tuesday 26 April 2011 09:15:22 Julien Ponge wrote:
> The company behind cmake is apparently really helpful. When KDE switched to
> cmake, they helped a lot and developed new features to fulfill the
> specific requirements KDE had. With the big names backing OpenJDK, I am
> pretty sure that the t
On 4/26/2011 7:54 AM, 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.
-kto
Well, I'd say that we should allo
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.
-kto
On Apr 26, 2011, at 12:57 AM, Steve Poole wrote:
>>>
>>> People can become quickly enthused (and stay with it to become a long
>>> term contributor) OR they go away and incorrectly assume OpenJDK isn't
>>> really open.
>> I'm concerned that your definition of "open" means we must strictly follo
There are other alternatives to cmake, including SCons and such.
I asked this because cmake is widely recognized as an excellent cross-platform
makefile generator, and you could probably get rid of the need for cygwin on MS
Windows. If gmake is the best option then fine, but exploring such alter
On 26/04/11 00:36, Kelly O'Hair wrote:
On Apr 24, 2011, at 12:17 PM, Lussier, Denis wrote:
My two cents are:
I think this is great. To say the least, it has historically been
challenging and/or non-standard to build OpenJDK (most especially on
Windoze).
Kelly, a big +1 for this proposal (is
* Julien Ponge:
> Did you consider using a tool like cmake to manage the build?
Isn't the documentation a bit hard to get? IIRC, it is a
self-published book which is not available from many book stores.
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsst
On 4/25/2011 4:49 PM, Kelly O'Hair wrote:
On Apr 25, 2011, at 3:46 AM, Erik Trimble wrote:
It would be a good idea to get this done as one of the first things, that way,
it makes it easier to attract new forks. Right now, the barrier to help is
quite high.
Attract new forks? What does that m
On Apr 25, 2011, at 3:46 AM, Erik Trimble wrote:
> I'd also like to add that an additional goal could be:
>
> * full documentation of the design (as well as the process) of the build
I'd agree to a guidelines and strategy document, that could benefit us in the
long run.
Not convinced a huge am
On Apr 24, 2011, at 1:46 PM, Alan Bateman wrote:
> Kelly O'Hair wrote:
>>
>> FYI...
>>
>> I sent this, but I'm not seeing any record it was received... :^(
>>
>> -kto
> I don't see it in the archives either.
>
> Anyway it is great to hear that the build will be getting attention, it's
> long
On Apr 24, 2011, at 12:17 PM, Lussier, Denis wrote:
> My two cents are:
>
> I think this is great. To say the least, it has historically been
> challenging and/or non-standard to build OpenJDK (most especially on
> Windoze).
Keep in mind, that our goals did not include meeting anyone's standar
I looked at it, and I'm not convinced it provides a great deal of benefits over
GNU make 3.81.
It seems to be missing anything with regards to dealing with building a jdk
image
(where there are 2 JDKs involved or a langtools javac building situation).
The JNI support seemed limited. And I saw not
Il giorno lun, 25/04/2011 alle 13.07 -0700, Erik Trimble ha scritto:
> Cmake sounds very promising.
>
> I would certainly think it merits a discussion of usefulness.
>
> The major barrier I'd say is that it would require us to do a forklift
> replacement of the existing gmake Makefile build syste
Cmake sounds very promising.
I would certainly think it merits a discussion of usefulness.
The major barrier I'd say is that it would require us to do a forklift
replacement of the existing gmake Makefile build system. That is, it is
unlikely that an incremental replacement of the gmake system co
Hi,
Did you consider using a tool like cmake to manage the build?
Cheers
On 25 avr. 2011, at 12:46, Erik Trimble wrote:
> On 4/24/2011 10:12 AM, Kelly O'Hair wrote:
>>
>>
>> FYI...
>>
>> I sent this, but I'm not seeing any record it was received... :^(
>>
>> -kto
>>
>>
>> Begin forwarded
My two cents are:
I think this is great. To say the least, it has historically been
challenging and/or non-standard to build OpenJDK (most especially on
Windoze).
I think first impressions when building a project are very important.
People can become quickly enthused (and stay with it to become a
34 matches
Mail list logo
