From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18498 invoked by alias); 1 Sep 2009 19:34:06 -0000 Received: (qmail 18487 invoked by uid 22791); 1 Sep 2009 19:34:06 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout5.012.net.il (HELO mtaout5.012.net.il) (84.95.2.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 01 Sep 2009 19:34:00 +0000 Received: from conversion-daemon.i_mtaout5.012.net.il by i_mtaout5.012.net.il (HyperSendmail v2004.12) id <0KPB003004U99C00@i_mtaout5.012.net.il> for gdb@sourceware.org; Tue, 01 Sep 2009 22:33:56 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.228.144.38]) by i_mtaout5.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KPB00GEA50K4421@i_mtaout5.012.net.il>; Tue, 01 Sep 2009 22:33:56 +0300 (IDT) Date: Tue, 01 Sep 2009 19:34:00 -0000 From: Eli Zaretskii Subject: Re: Build question In-reply-to: <1251828295.6106.119.camel@pavilion> To: danny.backx@scarlet.be Cc: tromey@redhat.com, gdb@sourceware.org Reply-to: Eli Zaretskii Message-id: <83zl9e8nro.fsf@gnu.org> References: <1250803105.11282.96.camel@pavilion> <83d46pgjkq.fsf@gnu.org> <1250877901.11282.116.camel@pavilion> <83ab1tgh9h.fsf@gnu.org> <1250880746.11282.128.camel@pavilion> <1250931899.11282.142.camel@pavilion> <83skfkfa4n.fsf@gnu.org> <1251095160.16357.352.camel@pavilion> <1251828295.6106.119.camel@pavilion> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00006.txt.bz2 > From: Danny Backx > Cc: tromey@redhat.com, gdb@sourceware.org > Date: Tue, 01 Sep 2009 20:04:55 +0200 > > Getting most things I care about to work is done by simplifying > include/filenames.h so it unconditionally takes the DOS versions of > IS_DIR_SEPARATOR() and IS_ABSOLUTE_PATH(). If Unix users will not be too unhappy about that, as Daniel says, I don't mind. But I still think it's a better idea to have a user-settable option to control that at runtime. > Apart from that, HAVE_DOS_BASED_FILE_SYSTEM is used in a number of > sources (even though filenames.h appears to do much already) : > ./libiberty/make-relative-prefix.c > ./libiberty/basename.c > ./libiberty/lbasename.c > ./include/filenames.h > ./bfd/archive.c > ./gdb/utils.c > ./gdb/cli/cli-cmds.c > ./gdb/completer.c > ./gdb/symtab.c > ./gdb/source.c > > Quick analysis : > > The code in bfd/archive.c could probably be cleaned up based on > IS_DIR_SEPARATOR. Even better, just use lbasename or even basename. > The code in gdb/utils.c could just always be compiled in. Again, if Unix users don't mind losing support for files of the form "d:foo". > Same, I think, for gdb/cli/cli-cmds.c. No, this one needs another macro: FILENAME_PREFIX_LEN, which should be 1 on Posix platforms and 3 on DOS-ish systems. Use the DOS-ish variant on Posix systems if "d:/foo" is not an important file name. > One part of gdb/completer.c is file name break characters. Not sure how > to deal with those. That one needs to be left as-is on DOS/Windows, but not on Unix. But this is just for completion, so it's not a grave problem for your use-case. > The other #if is no problem. Again, we need FILENAME_PREFIX_LEN here. See above. > The stuff in gdb/symtab.c does case independent string compare in the > DOS case. I see a need for FILENAME_CMPN here, similar to FILENAME_CMP that we already have. But using this on Unix is a bad idea, I think: you do NOT want case-insensitive file comparison there, do you? > gdb/source.c looks safe too. FILENAME_PREFIX_LEN again for the first hunk, something like realpath for the second, I think. Do we care about "d:" on Posix systems?