classpath-0.98 merge for GCC-4.4

classpath-0.98 merge for GCC-4.4

[Matthias Klose]

Looking forward at the the end of stage1 for GCC-4.4 and an upcoming
classpath-0.98 release ... Apparently cp won't be released before the end of
stage1, and GCC going directly from stage1 to stage3 would not allow a merge of
a new classpath. How should we proceed? Merge cp from the trunk as it is today,
and then ask for an exception for the merge of the final 0.98 release? Or ask
for an exception to merge the final cp release during stage3? The merges itself
should be straight forward.

  Matthias

Re: classpath-0.98 merge for GCC-4.4

[Andrew Haley]

Matthias Klose wrote:
> Looking forward at the the end of stage1 for GCC-4.4 and an upcoming
> classpath-0.98 release ... Apparently cp won't be released before the end of
> stage1, and GCC going directly from stage1 to stage3 would not allow a merge of
> a new classpath. How should we proceed? Merge cp from the trunk as it is today,
> and then ask for an exception for the merge of the final 0.98 release? Or ask
> for an exception to merge the final cp release during stage3? The merges itself
> should be straight forward.

As per the agreement we negotiated with the SC, libgcj has always had
a somewhat relaxed set of rules.  I can see no good reason not to merge
from cp today; it gives us a chance to test things and subsequent changes
in Stage 2 should be minor.

Andrew.

Re: classpath-0.98 merge for GCC-4.4

[Andrew John Hughes]

2008/8/11 Matthias Klose <doko@ubuntu.com>:
> Looking forward at the the end of stage1 for GCC-4.4 and an upcoming
> classpath-0.98 release ... Apparently cp won't be released before the end of
> stage1,

According to:

http://gcc.gnu.org/ml/gcc/2008-08/msg00131.html

the closing date for stage 1 is the 31st of August.  I think we should
be able to have a
GNU Classpath 0.98 release by then, hopefully well before then.  I was
nearing the point
of making a release, but had to stop to dedicate more time to the
OpenJDK challenge (my
original hope being that there would be a release much earlier, so
changes to Classpath could
also be part of the challenge project -- clearly this didn't work out).

Matthias, how long would you need between a Classpath release and the
deadline to port
the new version to GCJ? And is there any way I can help with this?

> and GCC going directly from stage1 to stage3 would not allow a merge of
> a new classpath. How should we proceed? Merge cp from the trunk as it is today,
> and then ask for an exception for the merge of the final 0.98 release? Or ask
> for an exception to merge the final cp release during stage3? The merges itself
> should be straight forward.

Ideally, I'd prefer a GCJ release to be based on a Classpath release,
if just so bug
reports against GCJ 4.4 can be more closely linked to a Classpath
release.  That said,
I think the tree is in okay shape at the moment.  If you do merge now,
I'd suggest using
the time to test the completed merge, especially the new locale changes.

As a third option, perhaps the main merge could be done now, covering
all the feature
changes (GJDoc, localisation).  I could then submit the remaining bug
fixes planned for 0.98
to GCJ separately, as they get sent to Classpath.  We'd then end up
with 0.98 in GCJ
(effectively).

>
>  Matthias
>

Thanks for handling this merge,
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

Re: classpath-0.98 merge for GCC-4.4

[Andrew Haley]

Andrew John Hughes wrote:

> Ideally, I'd prefer a GCJ release to be based on a Classpath
> release, if just so bug reports against GCJ 4.4 can be more
> closely linked to a Classpath release.

Me too.

> That said, I think the tree is in okay shape at the moment.  If
> you do merge now, I'd suggest using the time to test the
> completed merge, especially the new locale changes.

Yes.

> As a third option, perhaps the main merge could be done now,
> covering all the feature changes (GJDoc, localisation).  I
> could then submit the remaining bug fixes planned for 0.98 to
> GCJ separately, as they get sent to Classpath.  We'd then end
> up with 0.98 in GCJ (effectively).

That's my suggestion, as long as it doesn't make too much work
for Doko.

Andrew.

Re: classpath-0.98 merge for GCC-4.4

[Andrew John Hughes]

2008/8/11 Andrew Haley <aph@redhat.com>:
> Andrew John Hughes wrote:
>
>> Ideally, I'd prefer a GCJ release to be based on a Classpath
>> release, if just so bug reports against GCJ 4.4 can be more
>> closely linked to a Classpath release.
>
> Me too.
>
>> That said, I think the tree is in okay shape at the moment.  If
>> you do merge now, I'd suggest using the time to test the
>> completed merge, especially the new locale changes.
>
> Yes.
>
>> As a third option, perhaps the main merge could be done now,
>> covering all the feature changes (GJDoc, localisation).  I
>> could then submit the remaining bug fixes planned for 0.98 to
>> GCJ separately, as they get sent to Classpath.  We'd then end
>> up with 0.98 in GCJ (effectively).
>
> That's my suggestion, as long as it doesn't make too much work
> for Doko.
>

I'm happy to take on the second part i.e. pushing post-merge patches
to GCJ.  We can do this either on a patch-by-patch basis or as a second
smaller merge.

If we take this route, there are a couple of features I'd like to get
into Classpath
before the merge, java.util.Scanner and the javax.activation work from
ClasspathX.
Ideally, these are just merges themselves so should be trivial.
However, I won't be
able to do this until Thursday evening.  If someone else wants to do
it before then,
feel free :)

> Andrew.
>

-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

Re: classpath-0.98 merge for GCC-4.4

[Matthias Klose]

Andrew Haley schrieb:
> Andrew John Hughes wrote:
> 
>> Ideally, I'd prefer a GCJ release to be based on a Classpath
>> release, if just so bug reports against GCJ 4.4 can be more
>> closely linked to a Classpath release.
> 
> Me too.
> 
>> That said, I think the tree is in okay shape at the moment.  If
>> you do merge now, I'd suggest using the time to test the
>> completed merge, especially the new locale changes.
> 
> Yes.
> 
>> As a third option, perhaps the main merge could be done now,
>> covering all the feature changes (GJDoc, localisation).  I
>> could then submit the remaining bug fixes planned for 0.98 to
>> GCJ separately, as they get sent to Classpath.  We'd then end
>> up with 0.98 in GCJ (effectively).
> 
> That's my suggestion, as long as it doesn't make too much work
> for Doko.

I can start working on this on a merge branch. But being on a conference I'm not
sure that I will finish this before my vacation until the end of August. In the
past Joshua did offer to do a merge as well. Joshua, would you be able to work
on this merge as well?

  Matthias

Re: classpath-0.98 merge for GCC-4.4

[Joshua Sumali]

Matthias Klose wrote:
> Andrew Haley schrieb:
>   
>> Andrew John Hughes wrote:
>>
>>     
>>> Ideally, I'd prefer a GCJ release to be based on a Classpath
>>> release, if just so bug reports against GCJ 4.4 can be more
>>> closely linked to a Classpath release.
>>>       
>> Me too.
>>
>>     
>>> That said, I think the tree is in okay shape at the moment.  If
>>> you do merge now, I'd suggest using the time to test the
>>> completed merge, especially the new locale changes.
>>>       
>> Yes.
>>
>>     
>>> As a third option, perhaps the main merge could be done now,
>>> covering all the feature changes (GJDoc, localisation).  I
>>> could then submit the remaining bug fixes planned for 0.98 to
>>> GCJ separately, as they get sent to Classpath.  We'd then end
>>> up with 0.98 in GCJ (effectively).
>>>       
>> That's my suggestion, as long as it doesn't make too much work
>> for Doko.
>>     
>
> I can start working on this on a merge branch. But being on a conference I'm not
> sure that I will finish this before my vacation until the end of August. In the
> past Joshua did offer to do a merge as well. Joshua, would you be able to work
> on this merge as well?
>
>   Matthias
>   
I would like to, but I don't think I'll have the time to do so. My last 
day is on Wednesday and I can't guarantee any availability after that :(

Josh

Re: classpath-0.98 merge for GCC-4.4

[Matthias Klose]

Matthias Klose schrieb:
> Looking forward at the the end of stage1 for GCC-4.4 and an upcoming
> classpath-0.98 release ... Apparently cp won't be released before the end of
> stage1, and GCC going directly from stage1 to stage3 would not allow a merge of
> a new classpath. How should we proceed? Merge cp from the trunk as it is today,
> and then ask for an exception for the merge of the final 0.98 release? Or ask
> for an exception to merge the final cp release during stage3? The merges itself
> should be straight forward.

I started the merge on the branches/gcj/classpath-098-merge-branch branch. Far
from finished, but I'll be offline until September, so maybe somebody can use
this to continue. This merge seems to require more work than the 0.96 and 0.97
merges done before. The current state of the branch is: Configures, compiles,
class and header files regenerated, nothing more. Things that need to be done:

 - Backed out one nio update
   2008-04-18  Ian Rogers  <ian.rogers@manchester.ac.uk>
   Still needs to be merged.

 - StringBuffer, AbstractStringBuffer, VMCPStringBuilder merged/copied
   from classpath; needs some review.

 - the logic in tools/Makefile.am to disable gjdoc doesn't seem to work yet.

 - document the need to have antlr (and a working java) for maintainer mode
   builds.

 - the classpath configury cannot handle gcj as a compiler for the build;
   currently most of it is disabled, or unknown command line options are
   removed in the classpath configury, but maybe this should be addressed
   in classpath itself.

 - gmp could be enabled by default, at least it is required by gcc anyway.

Please feel free to work on the branch and/or remove it.

Matthias

Re: classpath-0.98 merge for GCC-4.4

[Andrew John Hughes]

On 15/08/2008, Matthias Klose <doko@ubuntu.com> wrote:
> Matthias Klose schrieb:
>
> > Looking forward at the the end of stage1 for GCC-4.4 and an upcoming
>  > classpath-0.98 release ... Apparently cp won't be released before the end of
>  > stage1, and GCC going directly from stage1 to stage3 would not allow a merge of
>  > a new classpath. How should we proceed? Merge cp from the trunk as it is today,
>  > and then ask for an exception for the merge of the final 0.98 release? Or ask
>  > for an exception to merge the final cp release during stage3? The merges itself
>  > should be straight forward.
>
>
> I started the merge on the branches/gcj/classpath-098-merge-branch branch. Far
>  from finished, but I'll be offline until September, so maybe somebody can use
>  this to continue. This merge seems to require more work than the 0.96 and 0.97
>  merges done before. The current state of the branch is: Configures, compiles,
>  class and header files regenerated, nothing more. Things that need to be done:
>

Thanks for getting this far :)

>   - Backed out one nio update
>    2008-04-18  Ian Rogers  <ian.rogers@manchester.ac.uk>
>    Still needs to be merged.
>

Ok not sure what this is but will take a look.

>   - StringBuffer, AbstractStringBuffer, VMCPStringBuilder merged/copied
>    from classpath; needs some review.
>

VMCPStringBuilder needs to use CNI in GCJ, I presume rather than the
overhead of reflection.  There already is an implementation in the
gnu.gcj namespace.

>   - the logic in tools/Makefile.am to disable gjdoc doesn't seem to work yet.
>

It does for me on Classpath.  What's the issue with the merge?

>   - document the need to have antlr (and a working java) for maintainer mode
>    builds.
>

This breaks down to --enable-maintainer-mode --disable-gjdoc when the
above works correctly.

>   - the classpath configury cannot handle gcj as a compiler for the build;
>    currently most of it is disabled, or unknown command line options are
>    removed in the classpath configury, but maybe this should be addressed
>    in classpath itself.
>

Can you be more specific? How is gcj being used as a compiler?  Note
that we now use the standard JAVAC= method to specify a specific
compiler, but this was new with 0.97 IIRC.

>   - gmp could be enabled by default, at least it is required by gcc anyway.
>

True.

>  Please feel free to work on the branch and/or remove it.
>
>
>  Matthias
>

Thanks again,
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

Re: classpath-0.98 merge for GCC-4.4

[Matthias Klose]

Andrew John Hughes schrieb:
> On 15/08/2008, Matthias Klose <doko@ubuntu.com> wrote:
>>   - Backed out one nio update
>>    2008-04-18  Ian Rogers  <ian.rogers@manchester.ac.uk>
>>    Still needs to be merged.
>>
> 
> Ok not sure what this is but will take a look.

see http://people.ubuntu.com/~doko/java/cpmerge.log

>>   - StringBuffer, AbstractStringBuffer, VMCPStringBuilder merged/copied
>>    from classpath; needs some review.
>>
> 
> VMCPStringBuilder needs to use CNI in GCJ, I presume rather than the
> overhead of reflection.  There already is an implementation in the
> gnu.gcj namespace.
> 
>>   - the logic in tools/Makefile.am to disable gjdoc doesn't seem to work yet.
>>
> 
> It does for me on Classpath.  What's the issue with the merge?

lib/Makefile.am and tools/Makefile.am are modified in gcj; likely that I did
mess up something.

>>   - document the need to have antlr (and a working java) for maintainer mode
>>    builds.
>>
> 
> This breaks down to --enable-maintainer-mode --disable-gjdoc when the
> above works correctly.
> 
>>   - the classpath configury cannot handle gcj as a compiler for the build;
>>    currently most of it is disabled, or unknown command line options are
>>    removed in the classpath configury, but maybe this should be addressed
>>    in classpath itself.
>>
> 
> Can you be more specific? How is gcj being used as a compiler?  Note
> that we now use the standard JAVAC= method to specify a specific
> compiler, but this was new with 0.97 IIRC.

currently we set JAVAC in the environment to gcj -C and let classpath pick up
this one. gcj doesn't understand options like -sourcepath, so I disabled these
in classpath (trying to check for the availability of -J using another unknown
option ;), and m4/ac_prog_javac.m4 tries to check for a working java compiler,
while we don't have yet when not building in maintainer mode.

  Matthias

Re: classpath-0.98 merge for GCC-4.4

[Andrew John Hughes]

On 15/08/2008, Matthias Klose <doko@ubuntu.com> wrote:
> Andrew John Hughes schrieb:
>
> > On 15/08/2008, Matthias Klose <doko@ubuntu.com> wrote:
>
> >>   - Backed out one nio update
>  >>    2008-04-18  Ian Rogers  <ian.rogers@manchester.ac.uk>
>  >>    Still needs to be merged.
>  >>
>  >
>  > Ok not sure what this is but will take a look.
>
>
> see http://people.ubuntu.com/~doko/java/cpmerge.log
>

Ahh, seems all the constructor calls were altered to allow the fields
to be final...

e.g.
        * java/nio/Buffer.java (cap): make field private and final.
        (address): make field final.
        (Buffer): add address argument to package protected constructor thereby
        allowing it to be made final.


>
>  >>   - StringBuffer, AbstractStringBuffer, VMCPStringBuilder merged/copied
>  >>    from classpath; needs some review.
>  >>
>  >
>  > VMCPStringBuilder needs to use CNI in GCJ, I presume rather than the
>  > overhead of reflection.  There already is an implementation in the
>  > gnu.gcj namespace.
>  >
>  >>   - the logic in tools/Makefile.am to disable gjdoc doesn't seem to work yet.
>  >>
>  >
>  > It does for me on Classpath.  What's the issue with the merge?
>
>
> lib/Makefile.am and tools/Makefile.am are modified in gcj; likely that I did
>  mess up something.
>
>
>  >>   - document the need to have antlr (and a working java) for maintainer mode
>  >>    builds.
>  >>
>  >
>  > This breaks down to --enable-maintainer-mode --disable-gjdoc when the
>  > above works correctly.
>  >
>  >>   - the classpath configury cannot handle gcj as a compiler for the build;
>  >>    currently most of it is disabled, or unknown command line options are
>  >>    removed in the classpath configury, but maybe this should be addressed
>  >>    in classpath itself.
>  >>
>  >
>  > Can you be more specific? How is gcj being used as a compiler?  Note
>  > that we now use the standard JAVAC= method to specify a specific
>  > compiler, but this was new with 0.97 IIRC.
>
>
> currently we set JAVAC in the environment to gcj -C and let classpath pick up
>  this one. gcj doesn't understand options like -sourcepath, so I disabled these
>  in classpath (trying to check for the availability of -J using another unknown
>  option ;), and m4/ac_prog_javac.m4 tries to check for a working java compiler,
>  while we don't have yet when not building in maintainer mode.
>

Ok, this makes sense, but how was it handled for 0.97?

>
>   Matthias
>
>

Thanks,
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8