From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30414 invoked by alias); 13 Oct 2004 13:54:09 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 30370 invoked from network); 13 Oct 2004 13:54:05 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 13 Oct 2004 13:54:05 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CHjZt-0007Hp-E9; Wed, 13 Oct 2004 09:54:05 -0400 Date: Wed, 13 Oct 2004 13:54:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Mark Kettenis , gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] Build inf-ptrace.o when ptrace available Message-ID: <20041013135405.GA27778@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Mark Kettenis , gdb-patches@sources.redhat.com References: <415DC09D.2070407@gnu.org> <200410012154.i91Ls6lE001359@elgar.sibelius.xs4all.nl> <41615D1E.8070007@gnu.org> <20041004143416.GA6653@nevyn.them.org> <416179DE.70401@gnu.org> <20041004163533.GA12898@nevyn.them.org> <416323A7.2010201@gnu.org> <20041005225914.GA28588@nevyn.them.org> <416AC1AC.6050207@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <416AC1AC.6050207@gnu.org> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-10/txt/msg00230.txt.bz2 On Mon, Oct 11, 2004 at 01:23:56PM -0400, Andrew Cagney wrote: > >I still do not believe that configure testing should be used for this > >purpose. If we end up moving the knowledge of natfiles into configure, > >then we can set inf-ptrace to be included for all native GNU/Linux > >targets easily enough. > > So you're not objecting to changes making configure (actually > configure.host and configure.tgt) directly handle what was previously in > the .mh file ... I thought I was being quite clear. You've presented two suggestions: - use autoconf to build inf-ptrace - goal: move natfiles into lists in the configure scripts I've said that I object to them both. I object strongly to the first, and stylisticly to the second. > >Or there are other ways to do it, as below. > > > >One of the reasons why I hold this position is that it lets us give a > >more useful error message if someone's system is broken and can not > >compile inf-ptrace.c for some reason that the configure script > >detected. They'll get either a link failure or a GDB which can't debug > >anything, instead of an error related to the compile problem. My > >experience with automating distribution builds tells me that someone > >will come up with a way to break their system in this fashion. > > .. but rather just objecting to having inf-ptrace selected dependant on > autoconf magic? I could equally hardwire it vis: > > case $host in > *-linux* | *-bsd* ) objs += inf-ptrace > esac > > Can you show us the money here - on what systems did you encounter > problems and what problems were they? > > The most recent problem I can think of was with the TUI, and that was a > straight configure.in bug. I wrote that my experience with automated builds suggested that a problem _would_ occur. I don't have an example of this problem occuring, but I don't think we need one to understand why it is an unsound design principle. The change would cause inf-ptrace to be built on more systems/configurations (where GDB wouldn't know how to use it), and could potentially cause it to be built on fewer systems (where GDB wouldn't work without it). No win. > >>>>>>>>>Why is it orthogonal? If we assume that configure determines when > >>>>>>/proc >>>and ptrace() and provides both to the user it certainly > >>>>>>isn't. Idea's >>>such as Mark's and mine would make it easier. > >>> > >>>>> > >>>>> > >>>>>Why is it related? How would this make it easier? It's not hard to > >>>>>add a new backend file to all the Linux targets; it's really not much > >>>>>different in a lot of little files than in one big one. I've done this > >>>>>plenty of times. > >> > >>> > >>>If we used configure.tgt and: > >>> switch "$target" > >>> *-*-linux* ) "objs=objs symfile-mem.c" > >>> esac > >>>then all GNU/Linux systems will always and consistently include > >>>symtab-mem.c. We don't, they don't ... > > > > > >This is no harder than having a common linux.mh, as GCC has done for > >years (gcc/config/t-linux). It's not a technical differece between > >configure-frobbing and makefile-fragmenting. > > So initially we can migrate things to configure.host, and then, if > things prove to unwieldly, look at refactoring it. But not before. So move everything out of makefile fragments before considering refactoring the makefile fragments? That doesn't make any sense. I will continue to object when you present this as a change with valid technical/maintenance advantages. If other maintainers agree that it has better style, I won't object to making the change, I've already said that. But I don't want to make a gratuituous change in style for bogus technical reasons. Something which can obviously be done in the current system is not a valid technical reason to discard the current system. -- Daniel Jacobowitz