Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning
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
Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning
- Original Message - > On August 20, 2015 7:35:37 PM GMT+02:00, Andrew Hughes > 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
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 jos...@codesourcery.com
Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning
On August 20, 2015 7:35:37 PM GMT+02:00, Andrew Hughes 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
- 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
- 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
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
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
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
On August 20, 2015 6:08:25 PM GMT+02:00, Andrew Haley 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
On August 20, 2015 5:52:55 PM GMT+02:00, Andrew Hughes 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
- 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
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
- 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
- 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
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
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
- 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
- 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
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
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
On Thu, Aug 20, 2015 at 4:48 AM, Andrew Hughes wrote: > - Original Message - >> On Fri, Aug 7, 2015 at 1:21 PM, Uros Bizjak 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 >> > >> > * 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
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
- Original Message - > On Fri, Aug 7, 2015 at 1:21 PM, Uros Bizjak 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 > > > > * 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
- 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
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
On Thu, Aug 13, 2015 at 11:31 PM, Jeff Law wrote: > On 08/13/2015 04:00 AM, Richard Biener wrote: >> >> On Wed, Aug 12, 2015 at 6:47 PM, Jeff Law wrote: >>> >>> On 08/12/2015 10:24 AM, Ian Lance Taylor wrote: On Wed, Aug 12, 2015 at 9:21 AM, Tom Tromey 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
On 08/13/2015 04:00 AM, Richard Biener wrote: On Wed, Aug 12, 2015 at 6:47 PM, Jeff Law wrote: On 08/12/2015 10:24 AM, Ian Lance Taylor wrote: On Wed, Aug 12, 2015 at 9:21 AM, Tom Tromey 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
On Wed, Aug 12, 2015 at 6:47 PM, Jeff Law wrote: > On 08/12/2015 10:24 AM, Ian Lance Taylor wrote: >> >> On Wed, Aug 12, 2015 at 9:21 AM, Tom Tromey 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
On Wed, Aug 12, 2015 at 9:47 AM, Jeff Law 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
On 08/12/2015 10:24 AM, Ian Lance Taylor wrote: On Wed, Aug 12, 2015 at 9:21 AM, Tom Tromey 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
On Wed, Aug 12, 2015 at 9:21 AM, Tom Tromey 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
On Wed, Aug 12, 2015 at 7:57 AM, Andrew Haley 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
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
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
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
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
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
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
On 08/11/2015 12:03 PM, Uros Bizjak wrote: On Fri, Aug 7, 2015 at 1:21 PM, Uros Bizjak 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 * 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
On Fri, Aug 7, 2015 at 1:21 PM, Uros Bizjak 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 > > * 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.