From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26259 invoked by alias); 17 May 2012 15:23:23 -0000 Received: (qmail 26246 invoked by uid 22791); 17 May 2012 15:23:22 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 17 May 2012 15:23:09 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3) with ESMTP id q4HFMYqT019788; Thu, 17 May 2012 17:22:34 +0200 (CEST) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3/Submit) id q4HFMWGM026439; Thu, 17 May 2012 17:22:32 +0200 (CEST) Date: Thu, 17 May 2012 15:23:00 -0000 Message-Id: <201205171522.q4HFMWGM026439@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: brobecker@adacore.com CC: macro@codesourcery.com, mark.kettenis@xs4all.nl, thomas@codesourcery.com, tromey@redhat.com, gdb-patches@sourceware.org, kevinb@redhat.com In-reply-to: <20120517123827.GB10253@adacore.com> (message from Joel Brobecker on Thu, 17 May 2012 05:38:27 -0700) Subject: Re: [SH] regs command References: <20120516142633.GV10253@adacore.com> <87zk98qe8t.fsf@schwinge.name> <20120516165730.GY10253@adacore.com> <87pqa4qbzp.fsf@schwinge.name> <87r4ukox0y.fsf@fleche.redhat.com> <20120516190539.GZ10253@adacore.com> <201205171109.q4HB9Ljc005742@glazunov.sibelius.xs4all.nl> <20120517123827.GB10253@adacore.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-05/txt/msg00655.txt.bz2 > Date: Thu, 17 May 2012 05:38:27 -0700 > From: Joel Brobecker > > > What's the technical reason and what do you propose as the alternative? > > Personally I see no problems with a hierarchical structure of initialisers > > as long as the hierarchy is well-defined so that people can rely on that. > > I can give you a name of a complex project that works very well with such > > an arrangement, and they actually have as many as eight levels. > > I would tend to agree with that, I don't see what we would have to lose > by doing so. I even thought that we could also include -nat files as > well in the mix. For instance: > - all files except the files to follow, in undefined order; > - all -nat files, in undefined order; > - all -tdep files, in undefined order. It's not obvious that such a hierarchy is the right one. I'd put the -tdep files before the -nat file for example. And I can imagine a scenario where you'd actually wanted the generic ones to come *after* the -tdep ones. I guess what I'm saying that I'm not convinced that the current case, the desire to deprecate a command that should never have been there in the first place, is necessarily a good case to base this decision on. Frankly, I would just remove the command in question, since it should never have been there in the first place.