From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48454 invoked by alias); 14 Aug 2015 07:44:00 -0000 Mailing-List: contact java-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-patches-owner@gcc.gnu.org Received: (qmail 48421 invoked by uid 89); 14 Aug 2015 07:43:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-io0-f181.google.com Received: from mail-io0-f181.google.com (HELO mail-io0-f181.google.com) (209.85.223.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 14 Aug 2015 07:43:57 +0000 Received: by iodv127 with SMTP id v127so61096857iod.3; Fri, 14 Aug 2015 00:43:55 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.157.69 with SMTP id g66mr1368304ioe.119.1439538235271; Fri, 14 Aug 2015 00:43:55 -0700 (PDT) Received: by 10.107.32.140 with HTTP; Fri, 14 Aug 2015 00:43:55 -0700 (PDT) In-Reply-To: <55CD0CC0.5050100@redhat.com> References: <55CA44C8.7000209@redhat.com> <87mvxxdxys.fsf@tromey.com> <55CB5BB7.4090703@redhat.com> <871tf81nrk.fsf@tromey.com> <55CB7885.6090900@redhat.com> <55CD0CC0.5050100@redhat.com> Date: Fri, 14 Aug 2015 07:44:00 -0000 Message-ID: Subject: Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning From: Richard Biener To: Jeff Law Cc: Ian Lance Taylor , Tom Tromey , Uros Bizjak , "gcc-patches@gcc.gnu.org" , GCJ-patches , Andrew Haley Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-q3/txt/msg00016.txt.bz2 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 >