[PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Uros Bizjak]

[-- Attachment #1: Type: text/plain, Size: 963 bytes --]

Hello!

Attached patch fixes:

Makefile:871: warning: overriding recipe for target 'gjdoc'
Makefile:786: warning: ignoring old recipe for target 'gjdoc'

build warning when compiling libjava.

The problem was in configure.ac: we have to depend gjdoc build on
CREATE_WRAPPERS in the same way as other tools are dependent a couple
of lines above.

While in this area, I also removed obsolete automake < 1.11
workaround. As mentioned in HACKING:  "Make sure you have Automake
1.11.1 installed. Exactly that version!"

I have included all generated files in the diff. The changes are small
and they illustrate the effect of the patch.

2015-08-07  Uros Bizjak  <ubizjak@gmail.com>

    * configure.ac (tools/gjdoc): Depend on CREATE_WRAPPERS.
    * configure: Regenerate.
    * tools/Makefile.am: Remove unneeded dependencies for Automake 1.11.
    * tools/Makefile.in: Regenerate.

Patch was bootstrapped on x86_64-linux-gnu, Fedora 22.

OK for GCC mainline?

Uros.

[-- Attachment #2: jc.diff.txt --]
[-- Type: text/plain, Size: 4218 bytes --]

Index: configure
===================================================================
--- configure	(revision 226715)
+++ configure	(working copy)
@@ -25874,11 +25874,15 @@
 
 if test "x${COMPILE_GJDOC}" = xyes
 then
-ac_config_files="$ac_config_files tools/gjdoc"
+if test -z "$CREATE_WRAPPERS_TRUE"; then :
+  else
+  ac_config_files="$ac_config_files tools/gjdoc"
 
 ac_config_commands="$ac_config_commands gjdoc"
 
+
 fi
+fi
 
 ac_config_commands="$ac_config_commands gen-classlist"
 
Index: configure.ac
===================================================================
--- configure.ac	(revision 226715)
+++ configure.ac	(working copy)
@@ -1256,8 +1256,10 @@
 
 if test "x${COMPILE_GJDOC}" = xyes
 then
-AC_CONFIG_FILES([tools/gjdoc])
+CLASSPATH_COND_IF([CREATE_WRAPPERS], [test "x${COMPILE_WRAPPERS}" = xyes], [],
+[AC_CONFIG_FILES([tools/gjdoc])
 AC_CONFIG_COMMANDS([gjdoc], [chmod 755 tools/gjdoc])
+])
 fi
 
 AC_CONFIG_COMMANDS([gen-classlist],[chmod 755 lib/gen-classlist.sh])
Index: tools/Makefile.am
===================================================================
--- tools/Makefile.am	(revision 226715)
+++ tools/Makefile.am	(working copy)
@@ -118,24 +118,7 @@
 noinst_SCRIPTS += gjdoc
 endif
 bin_PROGRAMS =
-## FIXME: remove these unneeded dependency lines once we can
-## require Automake 1.11.
-gappletviewer: gappletviewer.in
-gjarsigner: gjarsigner.in
-gkeytool: gkeytool.in
-gjar: gjar.in
-gnative2ascii: gnative2ascii.in
-gserialver: gserialver.in
-gjavah: gjavah.in
-grmiregistry: grmiregistry.in
-gtnameserv: gtnameserv.in
-gorbd: gorbd.in
-grmid: grmid.in
-grmic: grmic.in
-if CREATE_GJDOC
-gjdoc: gjdoc.in
 endif
-endif
 EXTRA_DIST = toolwrapper.c gappletviewer.in gjarsigner.in gkeytool.in \
 	gjar.in gnative2ascii.in gserialver.in gjavah.in grmiregistry.in \
 	gtnameserv.in gorbd.in grmid.in grmic.in gjdoc.in
Index: tools/Makefile.in
===================================================================
--- tools/Makefile.in	(revision 226715)
+++ tools/Makefile.in	(working copy)
@@ -782,8 +782,8 @@
 @CREATE_WRAPPERS_FALSE@	cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@
 @CREATE_WRAPPERS_FALSE@gjavah: $(top_builddir)/config.status $(srcdir)/gjavah.in
 @CREATE_WRAPPERS_FALSE@	cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@
-gjdoc: $(top_builddir)/config.status $(srcdir)/gjdoc.in
-	cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@
+@CREATE_WRAPPERS_FALSE@gjdoc: $(top_builddir)/config.status $(srcdir)/gjdoc.in
+@CREATE_WRAPPERS_FALSE@	cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@
 install-binPROGRAMS: $(bin_PROGRAMS)
 	@$(NORMAL_INSTALL)
 	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
@@ -867,9 +867,6 @@
 @CREATE_WRAPPERS_TRUE@gjavah$(EXEEXT): $(gjavah_OBJECTS) $(gjavah_DEPENDENCIES) $(EXTRA_gjavah_DEPENDENCIES) 
 @CREATE_WRAPPERS_TRUE@	@rm -f gjavah$(EXEEXT)
 @CREATE_WRAPPERS_TRUE@	$(gjavah_LINK) $(gjavah_OBJECTS) $(gjavah_LDADD) $(LIBS)
-@CREATE_GJDOC_FALSE@gjdoc$(EXEEXT): $(gjdoc_OBJECTS) $(gjdoc_DEPENDENCIES) $(EXTRA_gjdoc_DEPENDENCIES) 
-@CREATE_GJDOC_FALSE@	@rm -f gjdoc$(EXEEXT)
-@CREATE_GJDOC_FALSE@	$(gjdoc_LINK) $(gjdoc_OBJECTS) $(gjdoc_LDADD) $(LIBS)
 @CREATE_WRAPPERS_TRUE@gjdoc$(EXEEXT): $(gjdoc_OBJECTS) $(gjdoc_DEPENDENCIES) $(EXTRA_gjdoc_DEPENDENCIES) 
 @CREATE_WRAPPERS_TRUE@	@rm -f gjdoc$(EXEEXT)
 @CREATE_WRAPPERS_TRUE@	$(gjdoc_LINK) $(gjdoc_OBJECTS) $(gjdoc_LDADD) $(LIBS)
@@ -1342,19 +1339,6 @@
 	pdf pdf-am ps ps-am tags uninstall uninstall-am \
 	uninstall-binPROGRAMS uninstall-binSCRIPTS
 
-@CREATE_WRAPPERS_FALSE@gappletviewer: gappletviewer.in
-@CREATE_WRAPPERS_FALSE@gjarsigner: gjarsigner.in
-@CREATE_WRAPPERS_FALSE@gkeytool: gkeytool.in
-@CREATE_WRAPPERS_FALSE@gjar: gjar.in
-@CREATE_WRAPPERS_FALSE@gnative2ascii: gnative2ascii.in
-@CREATE_WRAPPERS_FALSE@gserialver: gserialver.in
-@CREATE_WRAPPERS_FALSE@gjavah: gjavah.in
-@CREATE_WRAPPERS_FALSE@grmiregistry: grmiregistry.in
-@CREATE_WRAPPERS_FALSE@gtnameserv: gtnameserv.in
-@CREATE_WRAPPERS_FALSE@gorbd: gorbd.in
-@CREATE_WRAPPERS_FALSE@grmid: grmid.in
-@CREATE_WRAPPERS_FALSE@grmic: grmic.in
-@CREATE_GJDOC_TRUE@@CREATE_WRAPPERS_FALSE@gjdoc: gjdoc.in
 
 # Make sure everything is included in the distribution.
 dist-hook:

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Uros Bizjak]

On Fri, Aug 7, 2015 at 1:21 PM, Uros Bizjak <ubizjak@gmail.com> wrote:

> Attached patch fixes:
>
> Makefile:871: warning: overriding recipe for target 'gjdoc'
> Makefile:786: warning: ignoring old recipe for target 'gjdoc'
>
> build warning when compiling libjava.
>
> The problem was in configure.ac: we have to depend gjdoc build on
> CREATE_WRAPPERS in the same way as other tools are dependent a couple
> of lines above.
>
> While in this area, I also removed obsolete automake < 1.11
> workaround. As mentioned in HACKING:  "Make sure you have Automake
> 1.11.1 installed. Exactly that version!"
>
> I have included all generated files in the diff. The changes are small
> and they illustrate the effect of the patch.
>
> 2015-08-07  Uros Bizjak  <ubizjak@gmail.com>
>
>     * configure.ac (tools/gjdoc): Depend on CREATE_WRAPPERS.
>     * configure: Regenerate.
>     * tools/Makefile.am: Remove unneeded dependencies for Automake 1.11.
>     * tools/Makefile.in: Regenerate.
>
> Patch was bootstrapped on x86_64-linux-gnu, Fedora 22.
>
> OK for GCC mainline?

I have committed this patch to GCC mainline SVN repository. Both
issues can be considered obvious and the fix is trivial.

Also, it looks like the official classpath repository is a dead place
for a couple of years.

Uros.

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Jeff Law]

On 08/11/2015 12:03 PM, Uros Bizjak wrote:
> On Fri, Aug 7, 2015 at 1:21 PM, Uros Bizjak <ubizjak@gmail.com> wrote:
>
>> Attached patch fixes:
>>
>> Makefile:871: warning: overriding recipe for target 'gjdoc'
>> Makefile:786: warning: ignoring old recipe for target 'gjdoc'
>>
>> build warning when compiling libjava.
>>
>> The problem was in configure.ac: we have to depend gjdoc build on
>> CREATE_WRAPPERS in the same way as other tools are dependent a couple
>> of lines above.
>>
>> While in this area, I also removed obsolete automake < 1.11
>> workaround. As mentioned in HACKING:  "Make sure you have Automake
>> 1.11.1 installed. Exactly that version!"
>>
>> I have included all generated files in the diff. The changes are small
>> and they illustrate the effect of the patch.
>>
>> 2015-08-07  Uros Bizjak  <ubizjak@gmail.com>
>>
>>      * configure.ac (tools/gjdoc): Depend on CREATE_WRAPPERS.
>>      * configure: Regenerate.
>>      * tools/Makefile.am: Remove unneeded dependencies for Automake 1.11.
>>      * tools/Makefile.in: Regenerate.
>>
>> Patch was bootstrapped on x86_64-linux-gnu, Fedora 22.
>>
>> OK for GCC mainline?
>
> I have committed this patch to GCC mainline SVN repository. Both
> issues can be considered obvious and the fix is trivial.
>
> Also, it looks like the official classpath repository is a dead place
> for a couple of years.
It's probably time for the occasional discussion WRT dropping 
gcj/libjava from the default languages and replace them with either Ada 
or Go.

gcj/libjava are dead IMHO.

Jeff

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Andrew Haley]

On 08/11/2015 07:54 PM, Jeff Law wrote:
> It's probably time for the occasional discussion WRT dropping 
> gcj/libjava from the default languages and replace them with either Ada 
> or Go.
> 
> gcj/libjava are dead IMHO.

I have no objections.  GCJ has been tremendously useful bootstrapping
the OpenJDK ecosystem, but we no longer need it in order to have free
Java.

Andrew.

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Jeff Law]

On 08/11/2015 01:24 PM, Andrew Haley wrote:
> On 08/11/2015 07:54 PM, Jeff Law wrote:
>> It's probably time for the occasional discussion WRT dropping
>> gcj/libjava from the default languages and replace them with either Ada
>> or Go.
>>
>> gcj/libjava are dead IMHO.
>
> I have no objections.  GCJ has been tremendously useful bootstrapping
> the OpenJDK ecosystem, but we no longer need it in order to have free
> Java.
Exactly.  With OpenJDK's state, GCJ just doesn't make sense as a first 
class citizen anymore.   GCJ may still have some value so I wouldn't 
recommend killing it completely ;-)


Jeff

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Tom Tromey]

Jeff> It's probably time for the occasional discussion WRT dropping
Jeff> gcj/libjava from the default languages and replace them with either
Jeff> Ada or Go.

It's long past time to remove it.  It's only had minimal maintenance for
years now.  No one is writing new features for it or fixing bugs.  There
aren't any significant users.

I've always felt I should be the one to pull the trigger.  If this is
acceptable I can take a stab at preparing a patch.

I thought maybe this would also enable deleting boehm-gc, zlib, or
libffi; but I see now they all have other users in the tree now.

Tom

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Jeff Law]

On 08/11/2015 08:47 PM, Tom Tromey wrote:
> Jeff> It's probably time for the occasional discussion WRT dropping
> Jeff> gcj/libjava from the default languages and replace them with either
> Jeff> Ada or Go.
>
> It's long past time to remove it.  It's only had minimal maintenance for
> years now.  No one is writing new features for it or fixing bugs.  There
> aren't any significant users.
>
> I've always felt I should be the one to pull the trigger.  If this is
> acceptable I can take a stab at preparing a patch.
>
> I thought maybe this would also enable deleting boehm-gc, zlib, or
> libffi; but I see now they all have other users in the tree now.
Just to be clear, I'm not talking about total removal, just removal from 
the default languages.

In the past this has stalled on issues like how will asynch-exceptions 
be tested and the like.

My inclination is to replace GCJ with Go, but Ian wasn't comfortable 
with that when I suggested it a couple years ago.  The other obvious 
alternative is Ada -- my testing showed that using Ada would further 
slow down bootstrap/regression test time which is undesirable.

I could live with either, but I'd lean towards Go.

jeff

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Andrew Haley]

On 12/08/15 15:44, Jeff Law wrote:
> My inclination is to replace GCJ with Go, but Ian wasn't comfortable 
> with that when I suggested it a couple years ago.

Because Go wasn't ready for prime time?

Andrew.

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Tom Tromey]

Jeff> In the past this has stalled on issues like how will asynch-exceptions
Jeff> be tested and the like.

It seems to me that either there is some other language which needs this
-- in which case that language ought to have testing for the feature --
or the feature is only used by gcj, in which case it doesn't matter.

Of course is!=ought; but relying on gcj and libjava to provide this
small amount of testing seems like a bad cost/benefit tradeoff.

Tom

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Ian Lance Taylor]

On Wed, Aug 12, 2015 at 7:57 AM, Andrew Haley <aph@redhat.com> wrote:
> On 12/08/15 15:44, Jeff Law wrote:
>> My inclination is to replace GCJ with Go, but Ian wasn't comfortable
>> with that when I suggested it a couple years ago.
>
> Because Go wasn't ready for prime time?

I don't remember why I wasn't comfortable with Go a couple of years
ago, but I think it would be OK as a default language today.  I doubt
it runs on as many platforms as gcj, though I would certainly be happy
to see more portability patches.  In particular, it doesn't currently
run on Windows or Darwin.

Ian

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Ian Lance Taylor]

On Wed, Aug 12, 2015 at 9:21 AM, Tom Tromey <tom@tromey.com> wrote:
> Jeff> In the past this has stalled on issues like how will asynch-exceptions
> Jeff> be tested and the like.
>
> It seems to me that either there is some other language which needs this
> -- in which case that language ought to have testing for the feature --
> or the feature is only used by gcj, in which case it doesn't matter.
>
> Of course is!=ought; but relying on gcj and libjava to provide this
> small amount of testing seems like a bad cost/benefit tradeoff.

Go does use asynchronous exceptions, and has test cases that rely on
them working.

Ian

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Jeff Law]

On 08/12/2015 10:24 AM, Ian Lance Taylor wrote:
> On Wed, Aug 12, 2015 at 9:21 AM, Tom Tromey <tom@tromey.com> wrote:
>> Jeff> In the past this has stalled on issues like how will asynch-exceptions
>> Jeff> be tested and the like.
>>
>> It seems to me that either there is some other language which needs this
>> -- in which case that language ought to have testing for the feature --
>> or the feature is only used by gcj, in which case it doesn't matter.
>>
>> Of course is!=ought; but relying on gcj and libjava to provide this
>> small amount of testing seems like a bad cost/benefit tradeoff.
>
> Go does use asynchronous exceptions, and has test cases that rely on
> them working.
If you're comfortable with Go at this point and we have mechanisms in 
place to ensure Go only gets built on platforms that support Go, then I 
think we should go forward with replacing GCJ with Go.

Jeff

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Ian Lance Taylor]

On Wed, Aug 12, 2015 at 9:47 AM, Jeff Law <law@redhat.com> wrote:
>
> If you're comfortable with Go at this point and we have mechanisms in place
> to ensure Go only gets built on platforms that support Go, then I think we
> should go forward with replacing GCJ with Go.

We have the mechanism for disabling Go on systems where it will not
work.  However, the list of such systems is undoubtedly incomplete at
this time.

In the top level configure.ac:

# Disable the go frontend on systems where it is known to not work. Please keep
# this in sync with contrib/config-list.mk.
case "${target}" in
*-*-darwin* | *-*-cygwin* | *-*-mingw* | *-*-aix*)
    unsupported_languages="$unsupported_languages go"
    ;;
esac

# Disable libgo for some systems where it is known to not work.
# For testing, you can easily override this with --enable-libgo.
if test x$enable_libgo = x; then
    case "${target}" in
    *-*-darwin*)
	# PR 46986
	noconfigdirs="$noconfigdirs target-libgo"
	;;
    *-*-cygwin* | *-*-mingw*)
	noconfigdirs="$noconfigdirs target-libgo"
	;;
    *-*-aix*)
	noconfigdirs="$noconfigdirs target-libgo"
	;;
    esac
fi

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Richard Biener]

On Wed, Aug 12, 2015 at 6:47 PM, Jeff Law <law@redhat.com> wrote:
> On 08/12/2015 10:24 AM, Ian Lance Taylor wrote:
>>
>> On Wed, Aug 12, 2015 at 9:21 AM, Tom Tromey <tom@tromey.com> wrote:
>>>
>>> Jeff> In the past this has stalled on issues like how will
>>> asynch-exceptions
>>> Jeff> be tested and the like.
>>>
>>> It seems to me that either there is some other language which needs this
>>> -- in which case that language ought to have testing for the feature --
>>> or the feature is only used by gcj, in which case it doesn't matter.
>>>
>>> Of course is!=ought; but relying on gcj and libjava to provide this
>>> small amount of testing seems like a bad cost/benefit tradeoff.
>>
>>
>> Go does use asynchronous exceptions, and has test cases that rely on
>> them working.
>
> If you're comfortable with Go at this point and we have mechanisms in place
> to ensure Go only gets built on platforms that support Go, then I think we
> should go forward with replacing GCJ with Go.

I think replacing it with Ada makes more sense (still have some
systems where a ton
of Go tests fail presumably because of too old glibc/kernel).

Or just replace it with nothing as effectively neither Go nor Ada are
going to be enabled
for all primary host platforms (as for Ada you need an Ada host
compiler for example).

Well.  My original idea was to strip down Java testing by basically
removing classpath
from the picture (to the extent of actually pruning it from the
repository apart from maybe
java.lang classes).

Richard.

> Jeff

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Jeff Law]

On 08/13/2015 04:00 AM, Richard Biener wrote:
> On Wed, Aug 12, 2015 at 6:47 PM, Jeff Law <law@redhat.com> wrote:
>> On 08/12/2015 10:24 AM, Ian Lance Taylor wrote:
>>>
>>> On Wed, Aug 12, 2015 at 9:21 AM, Tom Tromey <tom@tromey.com> wrote:
>>>>
>>>> Jeff> In the past this has stalled on issues like how will
>>>> asynch-exceptions
>>>> Jeff> be tested and the like.
>>>>
>>>> It seems to me that either there is some other language which needs this
>>>> -- in which case that language ought to have testing for the feature --
>>>> or the feature is only used by gcj, in which case it doesn't matter.
>>>>
>>>> Of course is!=ought; but relying on gcj and libjava to provide this
>>>> small amount of testing seems like a bad cost/benefit tradeoff.
>>>
>>>
>>> Go does use asynchronous exceptions, and has test cases that rely on
>>> them working.
>>
>> If you're comfortable with Go at this point and we have mechanisms in place
>> to ensure Go only gets built on platforms that support Go, then I think we
>> should go forward with replacing GCJ with Go.
>
> I think replacing it with Ada makes more sense (still have some
> systems where a ton
> of Go tests fail presumably because of too old glibc/kernel).
>
> Or just replace it with nothing as effectively neither Go nor Ada are
> going to be enabled
> for all primary host platforms (as for Ada you need an Ada host
> compiler for example).
Neither Ada nor Go are perfect.  However, Ada should be at a point 
where, if you have a suitable host compiler, it should build and 
regression test.

For Go, if there's platforms where the tests are unreliable, then it 
needs to be disabled on that platform until the tests are reliable. 
That's the key thing in my mind -- building and regression testing.

Thus I'd support either or both between Ada and Go.  In fact the more I 
think about it, the more I think both ought to be enabled and GCJ 
disabled for the default build.

jeff

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Richard Biener]

On Thu, Aug 13, 2015 at 11:31 PM, Jeff Law <law@redhat.com> wrote:
> On 08/13/2015 04:00 AM, Richard Biener wrote:
>>
>> On Wed, Aug 12, 2015 at 6:47 PM, Jeff Law <law@redhat.com> wrote:
>>>
>>> On 08/12/2015 10:24 AM, Ian Lance Taylor wrote:
>>>>
>>>>
>>>> On Wed, Aug 12, 2015 at 9:21 AM, Tom Tromey <tom@tromey.com> wrote:
>>>>>
>>>>>
>>>>> Jeff> In the past this has stalled on issues like how will
>>>>> asynch-exceptions
>>>>> Jeff> be tested and the like.
>>>>>
>>>>> It seems to me that either there is some other language which needs
>>>>> this
>>>>> -- in which case that language ought to have testing for the feature --
>>>>> or the feature is only used by gcj, in which case it doesn't matter.
>>>>>
>>>>> Of course is!=ought; but relying on gcj and libjava to provide this
>>>>> small amount of testing seems like a bad cost/benefit tradeoff.
>>>>
>>>>
>>>>
>>>> Go does use asynchronous exceptions, and has test cases that rely on
>>>> them working.
>>>
>>>
>>> If you're comfortable with Go at this point and we have mechanisms in
>>> place
>>> to ensure Go only gets built on platforms that support Go, then I think
>>> we
>>> should go forward with replacing GCJ with Go.
>>
>>
>> I think replacing it with Ada makes more sense (still have some
>> systems where a ton
>> of Go tests fail presumably because of too old glibc/kernel).
>>
>> Or just replace it with nothing as effectively neither Go nor Ada are
>> going to be enabled
>> for all primary host platforms (as for Ada you need an Ada host
>> compiler for example).
>
> Neither Ada nor Go are perfect.  However, Ada should be at a point where, if
> you have a suitable host compiler, it should build and regression test.
>
> For Go, if there's platforms where the tests are unreliable, then it needs
> to be disabled on that platform until the tests are reliable. That's the key
> thing in my mind -- building and regression testing.
>
> Thus I'd support either or both between Ada and Go.  In fact the more I
> think about it, the more I think both ought to be enabled and GCJ disabled
> for the default build.

I am testing all my patches with all,ada,obj-c++,go (where go works for me)
plus -m32 multilib.  I really think that we should simply enable all languages
by default (thus go with that patch fixing 'all').

Removing Java from the picture only makes sense if we remove it from
the repository - an untested language / runtime doesn't help anybody.
Thus my suggestion to strip it down to the "boostrap" enabler (which
is I believe even only requiring the VM!).  We do not need to build
classpath or libgcj - people can do that on their own.  gij is fine with
a bytecode / native programs after all.

So what about removing classpath from the repository?  We still
retain basic language support via java/ javax/ and gnu/ that way
I believe.

Richard.

> jeff
>

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Andrew Haley]

On 14/08/15 08:43, Richard Biener wrote:
> So what about removing classpath from the repository?  We still
> retain basic language support via java/ javax/ and gnu/ that way
> I believe.

I don't think we do.

Andrew.

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Andrew Hughes]

----- Original Message -----
> Jeff> It's probably time for the occasional discussion WRT dropping
> Jeff> gcj/libjava from the default languages and replace them with either
> Jeff> Ada or Go.
> 
> It's long past time to remove it.  It's only had minimal maintenance for
> years now.  No one is writing new features for it or fixing bugs.  There
> aren't any significant users.
> 
> I've always felt I should be the one to pull the trigger.  If this is
> acceptable I can take a stab at preparing a patch.
> 
> I thought maybe this would also enable deleting boehm-gc, zlib, or
> libffi; but I see now they all have other users in the tree now.
> 
> Tom
> 

No, it isn't. It's still a necessity for initial bootstrapping of OpenJDK/IcedTea.

By all means, disable it as a default but don't remove it.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Andrew Hughes]

----- Original Message -----
> On Fri, Aug 7, 2015 at 1:21 PM, Uros Bizjak <ubizjak@gmail.com> wrote:
> 
> > Attached patch fixes:
> >
> > Makefile:871: warning: overriding recipe for target 'gjdoc'
> > Makefile:786: warning: ignoring old recipe for target 'gjdoc'
> >
> > build warning when compiling libjava.
> >
> > The problem was in configure.ac: we have to depend gjdoc build on
> > CREATE_WRAPPERS in the same way as other tools are dependent a couple
> > of lines above.
> >
> > While in this area, I also removed obsolete automake < 1.11
> > workaround. As mentioned in HACKING:  "Make sure you have Automake
> > 1.11.1 installed. Exactly that version!"
> >
> > I have included all generated files in the diff. The changes are small
> > and they illustrate the effect of the patch.
> >
> > 2015-08-07  Uros Bizjak  <ubizjak@gmail.com>
> >
> >     * configure.ac (tools/gjdoc): Depend on CREATE_WRAPPERS.
> >     * configure: Regenerate.
> >     * tools/Makefile.am: Remove unneeded dependencies for Automake 1.11.
> >     * tools/Makefile.in: Regenerate.
> >
> > Patch was bootstrapped on x86_64-linux-gnu, Fedora 22.
> >
> > OK for GCC mainline?
> 
> I have committed this patch to GCC mainline SVN repository. Both
> issues can be considered obvious and the fix is trivial.
> 
> Also, it looks like the official classpath repository is a dead place
> for a couple of years.
> 

Hardly.

http://git.savannah.gnu.org/cgit/classpath.git/log/

I've taken the liberty of applying your patch to keep GCJ in sync with its
upstream.

> Uros.
> 

-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Tom Tromey]

Andrew> No, it isn't. It's still a necessity for initial bootstrapping of
Andrew> OpenJDK/IcedTea.

Andrew Haley said the opposite here:

https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00537.html

Tom

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Uros Bizjak]

On Thu, Aug 20, 2015 at 4:48 AM, Andrew Hughes <gnu.andrew@redhat.com> wrote:
> ----- Original Message -----
>> On Fri, Aug 7, 2015 at 1:21 PM, Uros Bizjak <ubizjak@gmail.com> wrote:
>>
>> > Attached patch fixes:
>> >
>> > Makefile:871: warning: overriding recipe for target 'gjdoc'
>> > Makefile:786: warning: ignoring old recipe for target 'gjdoc'
>> >
>> > build warning when compiling libjava.
>> >
>> > The problem was in configure.ac: we have to depend gjdoc build on
>> > CREATE_WRAPPERS in the same way as other tools are dependent a couple
>> > of lines above.
>> >
>> > While in this area, I also removed obsolete automake < 1.11
>> > workaround. As mentioned in HACKING:  "Make sure you have Automake
>> > 1.11.1 installed. Exactly that version!"
>> >
>> > I have included all generated files in the diff. The changes are small
>> > and they illustrate the effect of the patch.
>> >
>> > 2015-08-07  Uros Bizjak  <ubizjak@gmail.com>
>> >
>> >     * configure.ac (tools/gjdoc): Depend on CREATE_WRAPPERS.
>> >     * configure: Regenerate.
>> >     * tools/Makefile.am: Remove unneeded dependencies for Automake 1.11.
>> >     * tools/Makefile.in: Regenerate.
>> >
>> > Patch was bootstrapped on x86_64-linux-gnu, Fedora 22.
>> >
>> > OK for GCC mainline?
>>
>> I have committed this patch to GCC mainline SVN repository. Both
>> issues can be considered obvious and the fix is trivial.
>>
>> Also, it looks like the official classpath repository is a dead place
>> for a couple of years.
>>
>
> Hardly.
>
> http://git.savannah.gnu.org/cgit/classpath.git/log/

I was looking at

http://www.gnu.org/software/classpath/

where the lik still points to the CVS server, with the latest
ChangeLog entry from 2012-03-25. The repository you listed above can't
be found on what looks like a classpath start page.

> I've taken the liberty of applying your patch to keep GCJ in sync with its
> upstream.

Thanks!

Uros.

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Matthias Klose]

On 08/20/2015 06:36 AM, Tom Tromey wrote:
> Andrew> No, it isn't. It's still a necessity for initial bootstrapping of
> Andrew> OpenJDK/IcedTea.
> 
> Andrew Haley said the opposite here:
> 
> https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00537.html

if you need bootstrapping OpenJDK 6 or OpenJDK 7, then having gcj available for
the target platform is required. Starting with OpenJDK 8 you should be able to
cross build OpenJDK 8 with an OpenJDK 8 available on the cross platform.  It
might be possible to cross build older OpenJDK versions, but this usually is
painful.

Matthias

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Andrew Haley]

On 20/08/15 09:24, Matthias Klose wrote:
> On 08/20/2015 06:36 AM, Tom Tromey wrote:
>> Andrew> No, it isn't. It's still a necessity for initial bootstrapping of
>> Andrew> OpenJDK/IcedTea.
>>
>> Andrew Haley said the opposite here:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00537.html
> 
> if you need bootstrapping OpenJDK 6 or OpenJDK 7, then having gcj
> available for the target platform is required. Starting with OpenJDK
> 8 you should be able to cross build OpenJDK 8 with an OpenJDK 8
> available on the cross platform.  It might be possible to cross
> build older OpenJDK versions, but this usually is painful.

Sure, but we don't need GCJ going forward.  I don't think that there
are any new platforms to which OpenJDK has not been ported which will
require GCJ to bootstrap.  And even if there are, anybody who needs to
do that can (and, indeed, should) use an earlier version of GCJ.  It's
not going to go away; it will always be in the GCC repos.  And because
newer versions of GCC may break GCJ (and maybe OpenJDK) it makes more
sense to use an old GCC/GCJ for the bootstrapping of an old OpenJDK.

Andrew.

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Andrew Hughes]

----- Original Message -----
> On 20/08/15 09:24, Matthias Klose wrote:
> > On 08/20/2015 06:36 AM, Tom Tromey wrote:
> >> Andrew> No, it isn't. It's still a necessity for initial bootstrapping of
> >> Andrew> OpenJDK/IcedTea.
> >>
> >> Andrew Haley said the opposite here:
> >>
> >> https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00537.html
> > 
> > if you need bootstrapping OpenJDK 6 or OpenJDK 7, then having gcj
> > available for the target platform is required. Starting with OpenJDK
> > 8 you should be able to cross build OpenJDK 8 with an OpenJDK 8
> > available on the cross platform.  It might be possible to cross
> > build older OpenJDK versions, but this usually is painful.
> 
> Sure, but we don't need GCJ going forward.  I don't think that there
> are any new platforms to which OpenJDK has not been ported which will
> require GCJ to bootstrap.  And even if there are, anybody who needs to
> do that can (and, indeed, should) use an earlier version of GCJ.  It's
> not going to go away; it will always be in the GCC repos.  And because
> newer versions of GCC may break GCJ (and maybe OpenJDK) it makes more
> sense to use an old GCC/GCJ for the bootstrapping of an old OpenJDK.
> 

I don't see how we don't at present. How else do you solve the chicken-and-egg
situation of needing a JDK to build a JDK? I don't see crossing your fingers and
hoping there's a binary around somewhere as a very sustainable system.

From a personal point of view, I need gcj to make sure each new IcedTea 1.x and 2.x
release bootstraps. I don't plan to hold my system GCC at GCC 5 for the next decade
or however long we plan to support IcedTea 2.x / OpenJDK 7. It's also still noticeably
faster building with a native ecj than OpenJDK's javac.

It would cause me and others a lot of pain to remove gcj at this point. What exactly
is the reason to do so, other than some sudden whim?

> Andrew.
> 

-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Andrew Hughes]

----- Original Message -----
> Andrew> No, it isn't. It's still a necessity for initial bootstrapping of
> Andrew> OpenJDK/IcedTea.
> 
> Andrew Haley said the opposite here:
> 
> https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00537.html
> 

Andrew Haley doesn't do releases of IcedTea 1.x and 2.x every three
months. I do.

> Tom
> 

-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Andrew Haley]

On 08/20/2015 03:57 PM, Andrew Hughes wrote:
> ----- Original Message -----
>> On 20/08/15 09:24, Matthias Klose wrote:
>>> On 08/20/2015 06:36 AM, Tom Tromey wrote:
>>>> Andrew> No, it isn't. It's still a necessity for initial bootstrapping of
>>>> Andrew> OpenJDK/IcedTea.
>>>>
>>>> Andrew Haley said the opposite here:
>>>>
>>>> https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00537.html
>>>
>>> if you need bootstrapping OpenJDK 6 or OpenJDK 7, then having gcj
>>> available for the target platform is required. Starting with OpenJDK
>>> 8 you should be able to cross build OpenJDK 8 with an OpenJDK 8
>>> available on the cross platform.  It might be possible to cross
>>> build older OpenJDK versions, but this usually is painful.
>>
>> Sure, but we don't need GCJ going forward.  I don't think that there
>> are any new platforms to which OpenJDK has not been ported which will
>> require GCJ to bootstrap.  And even if there are, anybody who needs to
>> do that can (and, indeed, should) use an earlier version of GCJ.  It's
>> not going to go away; it will always be in the GCC repos.  And because
>> newer versions of GCC may break GCJ (and maybe OpenJDK) it makes more
>> sense to use an old GCC/GCJ for the bootstrapping of an old OpenJDK.
> 
> I don't see how we don't at present. How else do you solve the
> chicken-and-egg situation of needing a JDK to build a JDK? I don't
> see crossing your fingers and hoping there's a binary around
> somewhere as a very sustainable system.

That's what we do with GCC, binutils, etc: we bootstrap.

> From a personal point of view, I need gcj to make sure each new
> IcedTea 1.x and 2.x release bootstraps.

Sure, but all that does is test that the GCJ bootstrap still works.
And it's probably the only serious use of GCJ left.

> I don't plan to hold my system GCC at GCC 5 for the next decade or
> however long we plan to support IcedTea 2.x / OpenJDK 7. It's also
> still noticeably faster building with a native ecj than OpenJDK's
> javac.  It would cause me and others a lot of pain to remove gcj at
> this point. What exactly is the reason to do so, other than some
> sudden whim?

It's not a sudden whim: it's something we've been discussing for years.
The only reason GCJ is still alive is that I committed to keep it
going while we still needed it boot bootstrap OpenJDK.  Maintaining
GCJ in GCC is a significant cost, and GCJ has reached the end of its
natural life.  Classpath is substantially unmaintained, and GCJ
doesn't support any recent versions of Java.

Andrew.

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Jeff Law]

On 08/20/2015 09:27 AM, Andrew Haley wrote:
> On 08/20/2015 03:57 PM, Andrew Hughes wrote:
>> ----- Original Message -----
>>> On 20/08/15 09:24, Matthias Klose wrote:
>>>> On 08/20/2015 06:36 AM, Tom Tromey wrote:
>>>>> Andrew> No, it isn't. It's still a necessity for initial bootstrapping of
>>>>> Andrew> OpenJDK/IcedTea.
>>>>>
>>>>> Andrew Haley said the opposite here:
>>>>>
>>>>> https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00537.html
>>>>
>>>> if you need bootstrapping OpenJDK 6 or OpenJDK 7, then having gcj
>>>> available for the target platform is required. Starting with OpenJDK
>>>> 8 you should be able to cross build OpenJDK 8 with an OpenJDK 8
>>>> available on the cross platform.  It might be possible to cross
>>>> build older OpenJDK versions, but this usually is painful.
>>>
>>> Sure, but we don't need GCJ going forward.  I don't think that there
>>> are any new platforms to which OpenJDK has not been ported which will
>>> require GCJ to bootstrap.  And even if there are, anybody who needs to
>>> do that can (and, indeed, should) use an earlier version of GCJ.  It's
>>> not going to go away; it will always be in the GCC repos.  And because
>>> newer versions of GCC may break GCJ (and maybe OpenJDK) it makes more
>>> sense to use an old GCC/GCJ for the bootstrapping of an old OpenJDK.
>>
>> I don't see how we don't at present. How else do you solve the
>> chicken-and-egg situation of needing a JDK to build a JDK? I don't
>> see crossing your fingers and hoping there's a binary around
>> somewhere as a very sustainable system.
>
> That's what we do with GCC, binutils, etc: we bootstrap.
Right.  So the question is there some reason why OpenJDK can't be used 
to bootstrap itself?  Ie, is there a fundamental reason why Andrew needs 
to drop back down to GCJ and start the bootstrapping process from scratch.

ISTM that ideally the previous version of OpenJDK would be used to 
bootstrap the new version of OpenJDK.

Which leaves the question of how to deal with new platforms, but it 
sounds like there's a cross-compilation process starting with OpenJDK 8 
which ought to solve that problem.


>
>>  From a personal point of view, I need gcj to make sure each new
>> IcedTea 1.x and 2.x release bootstraps.
>
> Sure, but all that does is test that the GCJ bootstrap still works.
> And it's probably the only serious use of GCJ left.
And how much value is there in that in the real world?

>
> It's not a sudden whim: it's something we've been discussing for years.
> The only reason GCJ is still alive is that I committed to keep it
> going while we still needed it boot bootstrap OpenJDK.  Maintaining
> GCJ in GCC is a significant cost, and GCJ has reached the end of its
> natural life.  Classpath is substantially unmaintained, and GCJ
> doesn't support any recent versions of Java.
Right.  I think we last discuss this in 2013 and there was still some 
benefit in keeping GCJ building, but that benefit is dwindling over time.


There's an ongoing cost to every GCC developer to keep GCJ functional as 
changes in the core compiler happen.  Furthermore, there's a round-trip 
cost for every patch under development by every developer in the 
boostrap & testing cycles.

Given the marginal benefit to GCC and OpenJDK and the fairly high cost, 
we'd really prefer to drop GCJ.


Jeff

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Andrew Hughes]

----- Original Message -----
> On 08/20/2015 03:57 PM, Andrew Hughes wrote:
> > ----- Original Message -----
> >> On 20/08/15 09:24, Matthias Klose wrote:
> >>> On 08/20/2015 06:36 AM, Tom Tromey wrote:
> >>>> Andrew> No, it isn't. It's still a necessity for initial bootstrapping
> >>>> of
> >>>> Andrew> OpenJDK/IcedTea.
> >>>>
> >>>> Andrew Haley said the opposite here:
> >>>>
> >>>> https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00537.html
> >>>
> >>> if you need bootstrapping OpenJDK 6 or OpenJDK 7, then having gcj
> >>> available for the target platform is required. Starting with OpenJDK
> >>> 8 you should be able to cross build OpenJDK 8 with an OpenJDK 8
> >>> available on the cross platform.  It might be possible to cross
> >>> build older OpenJDK versions, but this usually is painful.
> >>
> >> Sure, but we don't need GCJ going forward.  I don't think that there
> >> are any new platforms to which OpenJDK has not been ported which will
> >> require GCJ to bootstrap.  And even if there are, anybody who needs to
> >> do that can (and, indeed, should) use an earlier version of GCJ.  It's
> >> not going to go away; it will always be in the GCC repos.  And because
> >> newer versions of GCC may break GCJ (and maybe OpenJDK) it makes more
> >> sense to use an old GCC/GCJ for the bootstrapping of an old OpenJDK.
> > 
> > I don't see how we don't at present. How else do you solve the
> > chicken-and-egg situation of needing a JDK to build a JDK? I don't
> > see crossing your fingers and hoping there's a binary around
> > somewhere as a very sustainable system.
> 
> That's what we do with GCC, binutils, etc: we bootstrap.
> 

True, but it's more amenable to cross-compilation than older versions
of OpenJDK. I guess we've been riding on the fact that we have gcc
available at an early stage on new systems and this allows us to get
easily to gcj and from there to IcedTea.

> > From a personal point of view, I need gcj to make sure each new
> > IcedTea 1.x and 2.x release bootstraps.
> 
> Sure, but all that does is test that the GCJ bootstrap still works.
> And it's probably the only serious use of GCJ left.
> 

Yes, but that's a feature I'm reluctant to suddenly drop in the late
stages of these projects.

We don't have it in IcedTea 3.x / OpenJDK 8 and so that usage will
go when we drop support for 7.

> > I don't plan to hold my system GCC at GCC 5 for the next decade or
> > however long we plan to support IcedTea 2.x / OpenJDK 7. It's also
> > still noticeably faster building with a native ecj than OpenJDK's
> > javac.  It would cause me and others a lot of pain to remove gcj at
> > this point. What exactly is the reason to do so, other than some
> > sudden whim?
> 
> It's not a sudden whim: it's something we've been discussing for years.
> The only reason GCJ is still alive is that I committed to keep it
> going while we still needed it boot bootstrap OpenJDK.  Maintaining
> GCJ in GCC is a significant cost, and GCJ has reached the end of its
> natural life.  Classpath is substantially unmaintained, and GCJ
> doesn't support any recent versions of Java.

Ok, I wasn't aware of this work. I follow this list but the only patches
I've really seen here are the occasional bumps from Matthias.

I don't want to keep it around forever either. Is there a way we can
stage the removal rather than going for a straight-out deletion so
dependants have more time to adapt to this? For example, can we flag
it as deprecated, take it out of defaults and the testsuite, etc. but
leave the code there at least for a little while longer? Basically,
whatever is needed to stop it being a burden to GCC developers without
removing it altogether.

Classpath is not unmaintained and has equally been kept going by me
over the years for similar reasons. It is overdue a merge into gcj
and I've been putting that off, both for want of a suitable point
to do so and the need to deal with the mess that is Subversion.

If gcj can be just kept around for a few more years, while the older
IcedTeas also wind down, I'll do whatever work is needed to keep it
going for my purposes, then we can finally remove it. But dropping it
altogether in the next six months is just too soon.

> 
> Andrew.
> 
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Andrew Hughes]

----- Original Message -----
> On 08/20/2015 09:27 AM, Andrew Haley wrote:
> > On 08/20/2015 03:57 PM, Andrew Hughes wrote:
> >> ----- Original Message -----
> >>> On 20/08/15 09:24, Matthias Klose wrote:
> >>>> On 08/20/2015 06:36 AM, Tom Tromey wrote:
> >>>>> Andrew> No, it isn't. It's still a necessity for initial bootstrapping
> >>>>> of
> >>>>> Andrew> OpenJDK/IcedTea.
> >>>>>
> >>>>> Andrew Haley said the opposite here:
> >>>>>
> >>>>> https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00537.html
> >>>>
> >>>> if you need bootstrapping OpenJDK 6 or OpenJDK 7, then having gcj
> >>>> available for the target platform is required. Starting with OpenJDK
> >>>> 8 you should be able to cross build OpenJDK 8 with an OpenJDK 8
> >>>> available on the cross platform.  It might be possible to cross
> >>>> build older OpenJDK versions, but this usually is painful.
> >>>
> >>> Sure, but we don't need GCJ going forward.  I don't think that there
> >>> are any new platforms to which OpenJDK has not been ported which will
> >>> require GCJ to bootstrap.  And even if there are, anybody who needs to
> >>> do that can (and, indeed, should) use an earlier version of GCJ.  It's
> >>> not going to go away; it will always be in the GCC repos.  And because
> >>> newer versions of GCC may break GCJ (and maybe OpenJDK) it makes more
> >>> sense to use an old GCC/GCJ for the bootstrapping of an old OpenJDK.
> >>
> >> I don't see how we don't at present. How else do you solve the
> >> chicken-and-egg situation of needing a JDK to build a JDK? I don't
> >> see crossing your fingers and hoping there's a binary around
> >> somewhere as a very sustainable system.
> >
> > That's what we do with GCC, binutils, etc: we bootstrap.
> Right.  So the question is there some reason why OpenJDK can't be used
> to bootstrap itself?  Ie, is there a fundamental reason why Andrew needs
> to drop back down to GCJ and start the bootstrapping process from scratch.
> 
> ISTM that ideally the previous version of OpenJDK would be used to
> bootstrap the new version of OpenJDK.
> 
> Which leaves the question of how to deal with new platforms, but it
> sounds like there's a cross-compilation process starting with OpenJDK 8
> which ought to solve that problem.
> 

The issue is that we're still supporting a version of OpenJDK/IcedTea where
there is no previous version (6). Once that goes, gcj could go too. This
is still just a little too soon.

> 
> >
> >>  From a personal point of view, I need gcj to make sure each new
> >> IcedTea 1.x and 2.x release bootstraps.
> >
> > Sure, but all that does is test that the GCJ bootstrap still works.
> > And it's probably the only serious use of GCJ left.
> And how much value is there in that in the real world?
> 

I do know it's been used recently on Gentoo to bootstrap IcedTea on
non-x86 archs. 

That's where it comes unstuck. How do you get a JDK built when there are
no JDK binaries for your architecture?

> >
> > It's not a sudden whim: it's something we've been discussing for years.
> > The only reason GCJ is still alive is that I committed to keep it
> > going while we still needed it boot bootstrap OpenJDK.  Maintaining
> > GCJ in GCC is a significant cost, and GCJ has reached the end of its
> > natural life.  Classpath is substantially unmaintained, and GCJ
> > doesn't support any recent versions of Java.
> Right.  I think we last discuss this in 2013 and there was still some
> benefit in keeping GCJ building, but that benefit is dwindling over time.
> 
> 
> There's an ongoing cost to every GCC developer to keep GCJ functional as
> changes in the core compiler happen.  Furthermore, there's a round-trip
> cost for every patch under development by every developer in the
> boostrap & testing cycles.
> 
> Given the marginal benefit to GCC and OpenJDK and the fairly high cost,
> we'd really prefer to drop GCJ.
> 

I'm not against this long-term, just not immediately. Deprecating it now
and removing it in the next release cycle (7?) would probably be enough,
but we need a little more time to wind down dependencies. I don't see us
needing it in a GCC released in 2017.

> 
> Jeff
> 
> 

-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Andrew Haley]

On 08/20/2015 05:03 PM, Andrew Hughes wrote:
> The issue is that we're still supporting a version of OpenJDK/IcedTea where
> there is no previous version (6).

Surely OpenJDK 6 can build itself.  And in the unlikely event of an
entirely new architecture which has No OpenJDK we'd have to grab an
old GCJ and build it with that.

If GCJ is included as part of GCC but is not maintained and tested, it
will soon rot.  That isn't an option IMO.

Andrew.

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Andrew Hughes]

----- Original Message -----
> On 08/20/2015 05:03 PM, Andrew Hughes wrote:
> > The issue is that we're still supporting a version of OpenJDK/IcedTea where
> > there is no previous version (6).
> 
> Surely OpenJDK 6 can build itself.  And in the unlikely event of an
> entirely new architecture which has No OpenJDK we'd have to grab an
> old GCJ and build it with that.
> 
> If GCJ is included as part of GCC but is not maintained and tested, it
> will soon rot.  That isn't an option IMO.
> 
> Andrew.
> 

I agree and I'm not saying keep it forever. Just give us a little time
to adapt to its removal by obsoleting now and removing it in the next
release cycle, rather than deleting it now six months before a release.

It's not just "entirely new architecture"s that have no OpenJDK, but
any system which, for whatever reason, doesn't have a binary available.

GCC follows this process of obsolescence then removal for ports (e.g. [0]).
I don't see why a language port should be any different.

[0] https://gcc.gnu.org/gcc-4.9/changes.html
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Richard Biener]

On August 20, 2015 5:52:55 PM GMT+02:00, Andrew Hughes <gnu.andrew@redhat.com> wrote:
>----- Original Message -----
>> On 08/20/2015 03:57 PM, Andrew Hughes wrote:
>> > ----- Original Message -----
>> >> On 20/08/15 09:24, Matthias Klose wrote:
>> >>> On 08/20/2015 06:36 AM, Tom Tromey wrote:
>> >>>> Andrew> No, it isn't. It's still a necessity for initial
>bootstrapping
>> >>>> of
>> >>>> Andrew> OpenJDK/IcedTea.
>> >>>>
>> >>>> Andrew Haley said the opposite here:
>> >>>>
>> >>>> https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00537.html
>> >>>
>> >>> if you need bootstrapping OpenJDK 6 or OpenJDK 7, then having gcj
>> >>> available for the target platform is required. Starting with
>OpenJDK
>> >>> 8 you should be able to cross build OpenJDK 8 with an OpenJDK 8
>> >>> available on the cross platform.  It might be possible to cross
>> >>> build older OpenJDK versions, but this usually is painful.
>> >>
>> >> Sure, but we don't need GCJ going forward.  I don't think that
>there
>> >> are any new platforms to which OpenJDK has not been ported which
>will
>> >> require GCJ to bootstrap.  And even if there are, anybody who
>needs to
>> >> do that can (and, indeed, should) use an earlier version of GCJ. 
>It's
>> >> not going to go away; it will always be in the GCC repos.  And
>because
>> >> newer versions of GCC may break GCJ (and maybe OpenJDK) it makes
>more
>> >> sense to use an old GCC/GCJ for the bootstrapping of an old
>OpenJDK.
>> > 
>> > I don't see how we don't at present. How else do you solve the
>> > chicken-and-egg situation of needing a JDK to build a JDK? I don't
>> > see crossing your fingers and hoping there's a binary around
>> > somewhere as a very sustainable system.
>> 
>> That's what we do with GCC, binutils, etc: we bootstrap.
>> 
>
>True, but it's more amenable to cross-compilation than older versions
>of OpenJDK. I guess we've been riding on the fact that we have gcc
>available at an early stage on new systems and this allows us to get
>easily to gcj and from there to IcedTea.
>
>> > From a personal point of view, I need gcj to make sure each new
>> > IcedTea 1.x and 2.x release bootstraps.
>> 
>> Sure, but all that does is test that the GCJ bootstrap still works.
>> And it's probably the only serious use of GCJ left.
>> 
>
>Yes, but that's a feature I'm reluctant to suddenly drop in the late
>stages of these projects.
>
>We don't have it in IcedTea 3.x / OpenJDK 8 and so that usage will
>go when we drop support for 7.
>
>> > I don't plan to hold my system GCC at GCC 5 for the next decade or
>> > however long we plan to support IcedTea 2.x / OpenJDK 7. It's also
>> > still noticeably faster building with a native ecj than OpenJDK's
>> > javac.  It would cause me and others a lot of pain to remove gcj at
>> > this point. What exactly is the reason to do so, other than some
>> > sudden whim?
>> 
>> It's not a sudden whim: it's something we've been discussing for
>years.
>> The only reason GCJ is still alive is that I committed to keep it
>> going while we still needed it boot bootstrap OpenJDK.  Maintaining
>> GCJ in GCC is a significant cost, and GCJ has reached the end of its
>> natural life.  Classpath is substantially unmaintained, and GCJ
>> doesn't support any recent versions of Java.
>
>Ok, I wasn't aware of this work. I follow this list but the only
>patches
>I've really seen here are the occasional bumps from Matthias.
>
>I don't want to keep it around forever either. Is there a way we can
>stage the removal rather than going for a straight-out deletion so
>dependants have more time to adapt to this? For example, can we flag
>it as deprecated, take it out of defaults and the testsuite, etc. but
>leave the code there at least for a little while longer? Basically,
>whatever is needed to stop it being a burden to GCC developers without
>removing it altogether.

Having classpath (with binary files!) In the GCC SVN (or future git) repository is a significant burden, not to mention the size of the distributed source tarball.

If we can get rid of that that would be a great step in reducing the burden.

Iff we can even without classpath build enough of java to be useful (do you really need gcj or only gij for bootstrapping openjdk? After all ecj is just a drop-in to gcc as well).

Richard.

>Classpath is not unmaintained and has equally been kept going by me
>over the years for similar reasons. It is overdue a merge into gcj
>and I've been putting that off, both for want of a suitable point
>to do so and the need to deal with the mess that is Subversion.
>
>If gcj can be just kept around for a few more years, while the older
>IcedTeas also wind down, I'll do whatever work is needed to keep it
>going for my purposes, then we can finally remove it. But dropping it
>altogether in the next six months is just too soon.
>
>> 
>> Andrew.
>> 

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Richard Biener]

On August 20, 2015 6:08:25 PM GMT+02:00, Andrew Haley <aph@redhat.com> wrote:
>On 08/20/2015 05:03 PM, Andrew Hughes wrote:
>> The issue is that we're still supporting a version of OpenJDK/IcedTea
>where
>> there is no previous version (6).
>
>Surely OpenJDK 6 can build itself.  And in the unlikely event of an
>entirely new architecture which has No OpenJDK we'd have to grab an
>old GCJ and build it with that.
>
>If GCJ is included as part of GCC but is not maintained and tested, it
>will soon rot.  That isn't an option IMO.

You only need a byte code interpreter on the target, no? No need for having native code in the first stage? So gij, witten in C++ is enough?

GCC basically carries the source load of a complete java (bytecode) stack just to make the bootstrap use native code in the first stage!?

Richard.

>Andrew.

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Andrew Haley]

On 08/20/2015 05:38 PM, Richard Biener wrote:
> So gij, witten in C++ is enough?

No: the runtime library needs gcj.

Andrew.

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Andrew Hughes]

snip...
> 
> Having classpath (with binary files!) In the GCC SVN (or future git)
> repository is a significant burden, not to mention the size of the
> distributed source tarball.
> 
> If we can get rid of that that would be a great step in reducing the burden.
> 
> Iff we can even without classpath build enough of java to be useful (do you
> really need gcj or only gij for bootstrapping openjdk? After all ecj is just
> a drop-in to gcc as well).

All the Java compilers are written in Java (ecj & javac). So to run them, you
need a JVM and its class library.

It's those binary files which allow gcj to bootstrap the stack. If OpenJDK
had a minimal binary class library, it would be able to bootstrap itself.

But, as things stand, you need enough of the JDK to run a Java compiler
and build the OpenJDK class libraries. GCJ currently fulfils that need
where there isn't already an OpenJDK installation available.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Andrew Hughes]

----- Original Message -----
> snip...
> > 
> > Having classpath (with binary files!) In the GCC SVN (or future git)
> > repository is a significant burden, not to mention the size of the
> > distributed source tarball.
> > 
> > If we can get rid of that that would be a great step in reducing the
> > burden.
> > 
> > Iff we can even without classpath build enough of java to be useful (do you
> > really need gcj or only gij for bootstrapping openjdk? After all ecj is
> > just
> > a drop-in to gcc as well).
> 
> All the Java compilers are written in Java (ecj & javac). So to run them, you
> need a JVM and its class library.
> 
> It's those binary files which allow gcj to bootstrap the stack. If OpenJDK
> had a minimal binary class library, it would be able to bootstrap itself.
> 
> But, as things stand, you need enough of the JDK to run a Java compiler
> and build the OpenJDK class libraries. GCJ currently fulfils that need
> where there isn't already an OpenJDK installation available.
> --

Actually, this makes me think...

IcedTea already depends on CACAO and JamVM for alternate builds of
OpenJDK. We could instead include the bytecode binaries for GNU Classpath
in IcedTea, bootstrap JamVM and use that to bootstrap OpenJDK. That
would remove our dependency on gcj and make IcedTea largely self-sufficient.
It would also mean we could drop a bunch of conditional code which depends
on what the system bootstrap JDK is, because it would always be the in-tree
solution.

We'd still need more than six months to make this transition though,
as such a change really needs time for testing.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Jeff Law]

On 08/20/2015 10:03 AM, Andrew Hughes wrote:
> ----- Original Message -----
>> On 08/20/2015 09:27 AM, Andrew Haley wrote:
>>> On 08/20/2015 03:57 PM, Andrew Hughes wrote:
>>>> ----- Original Message -----
>>>>> On 20/08/15 09:24, Matthias Klose wrote:
>>>>>> On 08/20/2015 06:36 AM, Tom Tromey wrote:
>>>>>>> Andrew> No, it isn't. It's still a necessity for initial bootstrapping
>>>>>>> of
>>>>>>> Andrew> OpenJDK/IcedTea.
>>>>>>>
>>>>>>> Andrew Haley said the opposite here:
>>>>>>>
>>>>>>> https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00537.html
>>>>>>
>>>>>> if you need bootstrapping OpenJDK 6 or OpenJDK 7, then having gcj
>>>>>> available for the target platform is required. Starting with OpenJDK
>>>>>> 8 you should be able to cross build OpenJDK 8 with an OpenJDK 8
>>>>>> available on the cross platform.  It might be possible to cross
>>>>>> build older OpenJDK versions, but this usually is painful.
>>>>>
>>>>> Sure, but we don't need GCJ going forward.  I don't think that there
>>>>> are any new platforms to which OpenJDK has not been ported which will
>>>>> require GCJ to bootstrap.  And even if there are, anybody who needs to
>>>>> do that can (and, indeed, should) use an earlier version of GCJ.  It's
>>>>> not going to go away; it will always be in the GCC repos.  And because
>>>>> newer versions of GCC may break GCJ (and maybe OpenJDK) it makes more
>>>>> sense to use an old GCC/GCJ for the bootstrapping of an old OpenJDK.
>>>>
>>>> I don't see how we don't at present. How else do you solve the
>>>> chicken-and-egg situation of needing a JDK to build a JDK? I don't
>>>> see crossing your fingers and hoping there's a binary around
>>>> somewhere as a very sustainable system.
>>>
>>> That's what we do with GCC, binutils, etc: we bootstrap.
>> Right.  So the question is there some reason why OpenJDK can't be used
>> to bootstrap itself?  Ie, is there a fundamental reason why Andrew needs
>> to drop back down to GCJ and start the bootstrapping process from scratch.
>>
>> ISTM that ideally the previous version of OpenJDK would be used to
>> bootstrap the new version of OpenJDK.
>>
>> Which leaves the question of how to deal with new platforms, but it
>> sounds like there's a cross-compilation process starting with OpenJDK 8
>> which ought to solve that problem.
>>
>
> The issue is that we're still supporting a version of OpenJDK/IcedTea where
> there is no previous version (6). Once that goes, gcj could go too. This
> is still just a little too soon.
But surely OpenJDK6 can build OpenJDK6, right?  I don't see you're 
fundamentally getting anything from always starting with a GCJ bootstrap.

>
> That's where it comes unstuck. How do you get a JDK built when there are
> no JDK binaries for your architecture?
Cross compilation, just like folks do for Ada.


>>
>
> I'm not against this long-term, just not immediately. Deprecating it now
> and removing it in the next release cycle (7?) would probably be enough,
> but we need a little more time to wind down dependencies. I don't see us
> needing it in a GCC released in 2017.
I was of the opinion that we should remove it from the default languages 
to be built.  Others wanted to be more aggressive :-)

jeff

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Andrew Hughes]

----- Original Message -----
> On 08/20/2015 10:03 AM, Andrew Hughes wrote:
> > ----- Original Message -----
> >> On 08/20/2015 09:27 AM, Andrew Haley wrote:
> >>> On 08/20/2015 03:57 PM, Andrew Hughes wrote:
> >>>> ----- Original Message -----
> >>>>> On 20/08/15 09:24, Matthias Klose wrote:
> >>>>>> On 08/20/2015 06:36 AM, Tom Tromey wrote:
> >>>>>>> Andrew> No, it isn't. It's still a necessity for initial
> >>>>>>> bootstrapping
> >>>>>>> of
> >>>>>>> Andrew> OpenJDK/IcedTea.
> >>>>>>>
> >>>>>>> Andrew Haley said the opposite here:
> >>>>>>>
> >>>>>>> https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00537.html
> >>>>>>
> >>>>>> if you need bootstrapping OpenJDK 6 or OpenJDK 7, then having gcj
> >>>>>> available for the target platform is required. Starting with OpenJDK
> >>>>>> 8 you should be able to cross build OpenJDK 8 with an OpenJDK 8
> >>>>>> available on the cross platform.  It might be possible to cross
> >>>>>> build older OpenJDK versions, but this usually is painful.
> >>>>>
> >>>>> Sure, but we don't need GCJ going forward.  I don't think that there
> >>>>> are any new platforms to which OpenJDK has not been ported which will
> >>>>> require GCJ to bootstrap.  And even if there are, anybody who needs to
> >>>>> do that can (and, indeed, should) use an earlier version of GCJ.  It's
> >>>>> not going to go away; it will always be in the GCC repos.  And because
> >>>>> newer versions of GCC may break GCJ (and maybe OpenJDK) it makes more
> >>>>> sense to use an old GCC/GCJ for the bootstrapping of an old OpenJDK.
> >>>>
> >>>> I don't see how we don't at present. How else do you solve the
> >>>> chicken-and-egg situation of needing a JDK to build a JDK? I don't
> >>>> see crossing your fingers and hoping there's a binary around
> >>>> somewhere as a very sustainable system.
> >>>
> >>> That's what we do with GCC, binutils, etc: we bootstrap.
> >> Right.  So the question is there some reason why OpenJDK can't be used
> >> to bootstrap itself?  Ie, is there a fundamental reason why Andrew needs
> >> to drop back down to GCJ and start the bootstrapping process from scratch.
> >>
> >> ISTM that ideally the previous version of OpenJDK would be used to
> >> bootstrap the new version of OpenJDK.
> >>
> >> Which leaves the question of how to deal with new platforms, but it
> >> sounds like there's a cross-compilation process starting with OpenJDK 8
> >> which ought to solve that problem.
> >>
> >
> > The issue is that we're still supporting a version of OpenJDK/IcedTea where
> > there is no previous version (6). Once that goes, gcj could go too. This
> > is still just a little too soon.
> But surely OpenJDK6 can build OpenJDK6, right?  I don't see you're
> fundamentally getting anything from always starting with a GCJ bootstrap.
> 

I'm talking about when you don't already have OpenJDK 6.

> >
> > That's where it comes unstuck. How do you get a JDK built when there are
> > no JDK binaries for your architecture?
> Cross compilation, just like folks do for Ada.
> 

Which still needs a JDK somewhere and, as Matthias mentioned, the build
system on older versions of OpenJDK (the ones were talking about) doesn't
really support cross-compilation. I had to hack around just to get x86 on
x86_64 to work.

> 
> >>
> >
> > I'm not against this long-term, just not immediately. Deprecating it now
> > and removing it in the next release cycle (7?) would probably be enough,
> > but we need a little more time to wind down dependencies. I don't see us
> > needing it in a GCC released in 2017.
> I was of the opinion that we should remove it from the default languages
> to be built.  Others wanted to be more aggressive :-)

I actually thought that change would have happened a long long time ago ;)

I'm actually for the aggressive approach, just on a longer time scale, as
I'll need time to transition IcedTea away from gcj.

> 
> jeff
> 

-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Richard Biener]

On August 20, 2015 7:35:37 PM GMT+02:00, Andrew Hughes <gnu.andrew@redhat.com> wrote:
>----- Original Message -----
>> snip...
>> > 
>> > Having classpath (with binary files!) In the GCC SVN (or future
>git)
>> > repository is a significant burden, not to mention the size of the
>> > distributed source tarball.
>> > 
>> > If we can get rid of that that would be a great step in reducing
>the
>> > burden.
>> > 
>> > Iff we can even without classpath build enough of java to be useful
>(do you
>> > really need gcj or only gij for bootstrapping openjdk? After all
>ecj is
>> > just
>> > a drop-in to gcc as well).
>> 
>> All the Java compilers are written in Java (ecj & javac). So to run
>them, you
>> need a JVM and its class library.
>> 
>> It's those binary files which allow gcj to bootstrap the stack. If
>OpenJDK
>> had a minimal binary class library, it would be able to bootstrap
>itself.
>> 
>> But, as things stand, you need enough of the JDK to run a Java
>compiler
>> and build the OpenJDK class libraries. GCJ currently fulfils that
>need
>> where there isn't already an OpenJDK installation available.
>> --
>
>Actually, this makes me think...
>
>IcedTea already depends on CACAO and JamVM for alternate builds of
>OpenJDK. We could instead include the bytecode binaries for GNU
>Classpath
>in IcedTea, bootstrap JamVM and use that to bootstrap OpenJDK. That
>would remove our dependency on gcj and make IcedTea largely
>self-sufficient.
>It would also mean we could drop a bunch of conditional code which
>depends
>on what the system bootstrap JDK is, because it would always be the
>in-tree
>solution.
>
>We'd still need more than six months to make this transition though,
>as such a change really needs time for testing.

OK, so how about deprecating Java for GCC 6 by removing it from the default languages and removing it for GCC 7 or before we switch to git (whatever happens earlier?)

Richard.

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Joseph Myers]

On Thu, 20 Aug 2015, Richard Biener wrote:

> OK, so how about deprecating Java for GCC 6 by removing it from the 
> default languages and removing it for GCC 7 or before we switch to git 
> (whatever happens earlier?)

I don't think "before we switch to git" should be a relevant consideration 
for any change to the contents of the source tree (all the libgcj files in 
SVN should be included in the git repository just like all the other 
history of all the branches in the repository - while I think there should 
be a fresh conversion to git, I don't think we should take the opportunity 
to remove anything from the history).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Andrew Hughes]

----- Original Message -----
> On August 20, 2015 7:35:37 PM GMT+02:00, Andrew Hughes
> <gnu.andrew@redhat.com> wrote:
> >----- Original Message -----
> >> snip...
> >> > 
> >> > Having classpath (with binary files!) In the GCC SVN (or future
> >git)
> >> > repository is a significant burden, not to mention the size of the
> >> > distributed source tarball.
> >> > 
> >> > If we can get rid of that that would be a great step in reducing
> >the
> >> > burden.
> >> > 
> >> > Iff we can even without classpath build enough of java to be useful
> >(do you
> >> > really need gcj or only gij for bootstrapping openjdk? After all
> >ecj is
> >> > just
> >> > a drop-in to gcc as well).
> >> 
> >> All the Java compilers are written in Java (ecj & javac). So to run
> >them, you
> >> need a JVM and its class library.
> >> 
> >> It's those binary files which allow gcj to bootstrap the stack. If
> >OpenJDK
> >> had a minimal binary class library, it would be able to bootstrap
> >itself.
> >> 
> >> But, as things stand, you need enough of the JDK to run a Java
> >compiler
> >> and build the OpenJDK class libraries. GCJ currently fulfils that
> >need
> >> where there isn't already an OpenJDK installation available.
> >> --
> >
> >Actually, this makes me think...
> >
> >IcedTea already depends on CACAO and JamVM for alternate builds of
> >OpenJDK. We could instead include the bytecode binaries for GNU
> >Classpath
> >in IcedTea, bootstrap JamVM and use that to bootstrap OpenJDK. That
> >would remove our dependency on gcj and make IcedTea largely
> >self-sufficient.
> >It would also mean we could drop a bunch of conditional code which
> >depends
> >on what the system bootstrap JDK is, because it would always be the
> >in-tree
> >solution.
> >
> >We'd still need more than six months to make this transition though,
> >as such a change really needs time for testing.
> 
> OK, so how about deprecating Java for GCC 6 by removing it from the default
> languages and removing it for GCC 7 or before we switch to git (whatever
> happens earlier?)
> 

Yeah, that's what I suggested at the end of [0] so +1 from me.

As Joseph says, I don't think the move to git is relevant to this. If it
had happened sooner, though, I'd have properly merged GNU Classpath more
frequently... ;)

> Richard.
> 
> 
> 

[0] https://gcc.gnu.org/ml/java-patches/2015-q3/msg00029.html
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Jeff Law]

On 08/20/2015 04:32 PM, Andrew Hughes wrote:
>>
>> OK, so how about deprecating Java for GCC 6 by removing it from the default
>> languages and removing it for GCC 7 or before we switch to git (whatever
>> happens earlier?)
>>
>
> Yeah, that's what I suggested at the end of [0] so +1 from me.
Works for me and is generally in-line with how we handle other 
deprecated components.

>
> As Joseph says, I don't think the move to git is relevant to this. If it
> had happened sooner, though, I'd have properly merged GNU Classpath more
> frequently... ;)
Agreed.

jeff