This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Monday 15 March 2010 06:47:33 Matt Rice wrote: > On Mon, Mar 15, 2010 at 12:08 AM, Mike Frysinger <vapier@gentoo.org> wrote: > >> not that I actually care about any such targets, but wouldn't this > >> just fall over on a case insentive filesystem? > > > > case insensitive is not the same thing as case preserving. assuming > > you're referring to the main ones (windows or OS X default), they're > > both case preserving. so files checked out as foo.s will stay as foo.s. > > the source code changes do string matches which have on relation at all > > to the file system the files reside upon. > > > > so no, i dont think this change will make any difference at all to such > > systems. otherwise you'd already see problems with the packages that > > utilize source files based on extension case. > > -mike > > Actually, i was thinking about the case-preserving thing, refreshing > my memory via google, pre-windows FAT filesystems (which i assume Eli > is using since he's not using long file names) case-destroy to > uppercase, which would just mean that they are pre-processing things > which don't need to be. > > > + set comp_output [target_compile $sourcefile ${name}.s > "preprocess" "incdir=$srcdir/$subdir"] > > is it possible for ${name}.s and $sourcefile somehow clash on > case-preserving case-insensitive filesystems when builddir==sourcedir? i guess the only way to handle this then would be to pipe it directly to the assembler ... -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |