From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7954 invoked by alias); 24 Apr 2002 01:54:26 -0000 Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org Received: (qmail 7885 invoked from network); 24 Apr 2002 01:54:18 -0000 Received: from unknown (HELO gash2.peakpeak.com) (207.174.178.17) by sources.redhat.com with SMTP; 24 Apr 2002 01:54:18 -0000 Received: from creche.cygnus.com (ta0193.peakpeak.com [204.144.244.193] (may be forged)) by gash2.peakpeak.com (8.9.3/8.9.3) with ESMTP id TAA10008; Tue, 23 Apr 2002 19:54:11 -0600 Received: (from tromey@localhost) by creche.cygnus.com (8.9.3/8.9.3) id UAA24935; Tue, 23 Apr 2002 20:00:13 -0600 To: Bryce McKinlay Cc: akos.szalay@sophos.com, java@gcc.gnu.org Subject: Re: -D ? References: <873cxmf5wn.fsf@creche.redhat.com> <3CC5F416.7050808@waitaki.otago.ac.nz> From: Tom Tromey Reply-To: tromey@redhat.com X-Attribution: Tom X-Zippy: .. I think I'd better go back to my DESK and toy with a few common MISAPPREHENSIONS... Date: Tue, 23 Apr 2002 18:57:00 -0000 In-Reply-To: Bryce McKinlay's message of "Wed, 24 Apr 2002 11:53:58 +1200" Message-ID: <87bsc9c0us.fsf@creche.redhat.com> X-SW-Source: 2002-04/txt/msg00333.txt.bz2 >>>>> "Bryce" == Bryce McKinlay writes: >> gcj should only be used for compiling Java >> code (either .java, .class, or resource files with --resource). Bryce> Why? It might not be a good idea to compile JNI code with gcj, Bryce> but it can be very useful to use gcj to compile and link C/C++ Bryce> code into a mixed Java/C++ application. But, it is unfortunate Bryce> that the -D flag means different things to Java and C code. We already broke compatibility with -C. Admittedly this isn't useful in the situation you cite. I think my bias here is that I'm not used to compiling things that way. I almost always compile to .o files first. The problem to me is just one of supportability. I don't think we've ever advertised this feature. We don't test it (more precisely, I don't know of anybody testing it). Supporting it means one more place that we have to watch what happens in the C/C++ front ends to make sure we don't have problems; this is hard because those front ends are 5x-10x as active as we are. So in sum to me it seems like it isn't worth the effort. Still, I don't feel all that strongly about it. We could probably devise a plan to rehabilitate -D (e.g., nearly-compatible change in 3.2, real change in 3.3). Tom