From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13667 invoked by alias); 13 Dec 2002 20:44:11 -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 13655 invoked from network); 13 Dec 2002 20:44:10 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by 209.249.29.67 with SMTP; 13 Dec 2002 20:44:10 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 97BF63D07; Fri, 13 Dec 2002 15:43:01 -0500 (EST) Message-ID: <3DFA4655.6050007@redhat.com> Date: Fri, 13 Dec 2002 12:47:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.1) Gecko/20021211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA/commit] Add new file hppa-hpux-tdep.c References: <20021213175903.GC25575@gnat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-12/txt/msg00431.txt.bz2 > I am adding a new file, were all the hpux-specific stuff should go. > > I am treating this as a semi-RFA, despite the multiarch rule, because: > - Despite Andrew's recommendation to name the files pa-* to follow > the name of the directory where the config files are stored, I > kept hppa because it's what is used in the configuration triplet. > If I had to change anything, I'd prefer to change the name of the > directory... Well, the directory config/pa will eventually go away :-) > - There is also this fnchange.lst file, which I don't understand > completely. The documentation says I should add a new line for > each file that does not respect the 8.3 format. But it does not > say what should be there. I thought it should be @V.../longname > followed by @V.../8+3name. But I saw many exceptions, and many > entries missing. So I'm not sure what I should do for this patch. > Eli? Only the files with 8.3 name clashes need a rename. So areallylongfilename.c is ok provided there isn't also areallylongsecondfilename.c :-) (perhaps the doco needs clarifying?) Andrew