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

[Richard Biener <richard.guenther@gmail.com>]

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.
>>