public inbox for java-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Matthias Klose <doko@ubuntu.com>
To: Jon VanAlten <jon.vanalten@redhat.com>
Cc: GCJ-patches <java-patches@gcc.gnu.org>,
	 Tom Tromey <tromey@redhat.com>, Andrew Haley <aph@redhat.com>
Subject: Re: ping: Re: [patch] update ecj to ecj-3.8.2/4.2.2
Date: Tue, 02 Jul 2013 09:36:00 -0000	[thread overview]
Message-ID: <51D29F0E.2000400@ubuntu.com> (raw)
In-Reply-To: <1465929016.3776725.1372274627134.JavaMail.root@redhat.com>

On 06/26/13 21:23, Jon VanAlten wrote:
> 
> 
> ----- Original Message -----
>> From: "Matthias Klose" <doko@ubuntu.com>
>> To: "GCJ-patches" <java-patches@gcc.gnu.org>
>> Cc: "Jon VanAlten" <jon.vanalten@redhat.com>, "Tom Tromey" <tromey@redhat.com>, "Andrew Haley" <aph@redhat.com>
>> Sent: Thursday, June 20, 2013 6:39:22 AM
>> Subject: ping: Re: [patch] update ecj to ecj-3.8.2/4.2.2
>>
>> ping
>>
>> Am 15.04.2013 12:21, schrieb Matthias Klose:
>>> The ecj.jar provided on ftp://gcc.gnu.org/pub/java wasn't updated anymore
>>> since
>>> 2008, having no support for java7.  It looks like this ecj is already used
>>> within the Fedora disto, however only locally patched (at least I couldn't
>>> find
>>> any mail sent to java-patches).
>>>
>>> Find attached the changes required to build a new ecj.jar from the R3_8_2
>>> git
>>> tag.  The built files can be found at
>>> http://people.debian.org/~doko/tmp/eclipse-gcj/. The resulting gcj -C looks
>>> fine, building libjava with the new ecj.jar doesn't show any regressions,
>>> and
>>> the testsuite doesn't show any regressions.  However the filenames for some
>>> generated class and header files have changed for inner classes:
>>>
>>> $ svn status|grep UIDefaults|sort -k1
>>> !       classpath/lib/javax/swing/UIDefaults$1.class
>>> !       classpath/lib/javax/swing/UIDefaults$2.class
>>> !       classpath/lib/javax/swing/UIDefaults$3.class
>>> !       classpath/lib/javax/swing/UIDefaults$4.class
>>> ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$1.class
>>> ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$2.class
>>> ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$3.class
>>> ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$4.class
>>> !       javax/swing/UIDefaults$1.h
>>> !       javax/swing/UIDefaults$2.h
>>> !       javax/swing/UIDefaults$3.h
>>> !       javax/swing/UIDefaults$4.h
>>> ?       javax/swing/UIDefaults$ProxyLazyValue$1.h
>>> ?       javax/swing/UIDefaults$ProxyLazyValue$2.h
>>> ?       javax/swing/UIDefaults$ProxyLazyValue$3.h
>>> ?       javax/swing/UIDefaults$ProxyLazyValue$4.h
>>> M       classpath/lib/javax/swing/plaf/basic/SharedUIDefaults.class
>>> M       classpath/lib/javax/swing/UIDefaults.class
>>> M       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue.class
>>> M
>>> classpath/lib/javax/swing/UIManager$MultiplexUIDefaults$MultiplexEnumeration.class
>>>
>>> See the attached svn-status.gz file for a complete diff (replace ! with D,
>>> ?
>>> with A).
>>>
>>>  - I'd like to ask Tom (or somebody else) to look at the patches
>>>    for the rhug/java repository.
>>>
>>>  - Ask to rebuild the .class and .h files using this new ecj.jar on the
>>>  trunk,
>>>    after the ecj.jar is uploaded.
>>>
>>> There are issues building OpenJDK and IcedTea with this new compiler.
>>> Please
>>> see the IcedTea ML for a follow-up posting.
>>>
>>>   Matthias
>>>
> 
> Hi Matthias,
> 
> I didn't realize this was still waiting for input.
> /me puts on Fedora packager hat...
> We don't even use the Makefile here (we copy GCCMain and properties
> into ecj source tree and use their ant build), but I have a couple
> comments about that change anyways.
> 
>  checkout:
> -	cvs -d $(cvsroot) co -r$(TAG) org.eclipse.jdt.core
> +#	git clone -b R3_8_maintenance git://git.eclipse.org/gitroot/jdt/eclipse.jdt.core.git
> +#	wget http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/snapshot/$(TAG).tar.gz
> +	tar xf $(TAG).tar.gz
> 
> So "checkout" target no longer does a checkout... seems a bit off. Is
> the commented git clone line left over from doing some of this before
> the official tag existed? Might want to drop that, and consider
> renaming the target to reflect its new behaviour.

sure, I can rename that.  any suggestion?  The purpose is to make it clear where
the source do come from.

> +	tar -c -f - -C $(TAG)/org.eclipse.jdt.core/compiler org \
> +	  | tar -x -f - -C org.eclipse.jdt.core/
> 
> Am I missing something or is this equivalent and simpler:
> 
> +	mv $(TAG)/org.eclipse.jdt.core/compiler/org org.eclipse.jdt.core/
> 
> +	tar -c -f - -C $(TAG)/org.eclipse.jdt.core/batch org \
> +	  | tar -x -f - -C org.eclipse.jdt.core/
> 
> Ditto.

yes, not having to run the checkout / pull from the web again.

> 
> -	cp org.eclipse.jdt.core/META-INF/MANIFEST.MF $(OUTPUT)/META-INF
> +#	cp org.eclipse.jdt.core/META-INF/MANIFEST.MF $(OUTPUT)/META-INF
> 
> Any reason not to just delete this line if it's no longer needed?

sure, can be dropped, the file is generated by jar anyway.

> As for the GCCMain portion of the change, yes it looks both necessary
> and correct. We do same in Fedora package (once again sorry it didn't
> get posted upstream due to my ignorance), and it would be nice to drop
> the patch once this is in a release.

yes, having this upstream would be appreciated.

So besides the style how to do fetch the sources, this looks ok?

Is there another newer released ecj version which should be used instead?

  Matthias

  reply	other threads:[~2013-07-02  9:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-15 10:21 Matthias Klose
2013-04-15 13:29 ` Andrew Hughes
2013-04-15 13:50   ` Matthias Klose
2013-04-15 14:02     ` Andrew Hughes
2013-04-15 14:08       ` Matthias Klose
2013-04-15 14:22         ` Andrew Hughes
2013-04-15 14:44 ` Jon VanAlten
2013-04-15 21:34   ` Andrew Hughes
2013-04-15 22:39     ` Jon VanAlten
2013-06-20 12:39 ` ping: " Matthias Klose
2013-06-26 19:23   ` Jon VanAlten
2013-07-02  9:36     ` Matthias Klose [this message]
2013-07-02 19:04       ` Jon VanAlten
2013-12-10 15:51         ` Matthias Klose
2013-12-10 16:05           ` Andrew Haley
2013-12-10 16:23             ` Matthias Klose

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51D29F0E.2000400@ubuntu.com \
    --to=doko@ubuntu.com \
    --cc=aph@redhat.com \
    --cc=java-patches@gcc.gnu.org \
    --cc=jon.vanalten@redhat.com \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).