From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17481 invoked by alias); 16 Sep 2002 22:17:35 -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 17474 invoked from network); 16 Sep 2002 22:17:34 -0000 Received: from unknown (HELO msgbas1.cos.agilent.com) (192.25.240.36) by sources.redhat.com with SMTP; 16 Sep 2002 22:17:34 -0000 Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 10823BD42; Mon, 16 Sep 2002 16:17:34 -0600 (MDT) Received: from websvr.canada.agilent.com (websvr.canada.agilent.com [141.184.122.102]) by relcos1.cos.agilent.com (Postfix) with ESMTP id 5696943B; Mon, 16 Sep 2002 16:17:09 -0600 (MDT) Received: from agilent.com (dhcp6burnaby.canada.agilent.com [141.184.123.147]) by websvr.canada.agilent.com (8.9.3 (PHNE_25183)/8.9.3 SMKit7.1.1_Agilent) with ESMTP id PAA20094; Mon, 16 Sep 2002 15:17:24 -0700 (PDT) Message-ID: <3D865872.76E01CC7@agilent.com> Date: Mon, 16 Sep 2002 15:17:00 -0000 From: Earl Chew Organization: Agilent Technologies X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com, cgf@redhat.com Subject: Re: [RFC PATCH] Finding files in source trees (was Re: Finding source files under Cygwin) References: <3D82897C.81376AD6@agilent.com> <3D862BD0.A5298600@agilent.com> <3D864101.2A0BCA85@agilent.com> <20020916220207.GA32278@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg00324.txt.bz2 Daniel Jacobowitz wrote: > This patch needs a lot more testing before I'd be comfortable with it. > We went to a fair amount of trouble to support finding the right file > when multiple files have the same name. > > For instance, given: > dir /a:/b > filename foo/bar.c > > files /a/bar.c /b/foo/bar.c > > will your patch find /b/foo/bar.c? I don't think it will. Hmm... I think it will. The patch doesn't replace any of the existing code in open_source_file() --- it adds an extra search option at the end of the function. In pseudo-code: a. return s->fullname if present // Previously resolved name b. if s->dirname available replace $cdir in path c. search for s->filename in path d. if not found, search for lbasename(s->filename) in path + e. if not found, repeatedly lop separators from head + of s->filename and search in path (My addition is indicated with +) > For instance, given: > dir /a:/b > filename foo/bar.c > > files /a/bar.c /b/foo/bar.c > > will your patch find /b/foo/bar.c? I don't think it will. In your example, I'm pretty sure foo/bar.c will be found at step (c). My patch at step (e) will only triggered as a last resort, when open_source_file couldn't find the file anywhere else. Earl