Path: chuka.playstation.co.uk!tjs From: tjs@cs.monash.edu.au (Toby Sargeant) Newsgroups: scee.yaroze.programming.gnu_compiler Subject: Re: Long file names in #include's Date: 12 Oct 1999 22:24:35 GMT Organization: PlayStation Net Yaroze (SCEE) Lines: 34 Message-ID: References: <01bf1496$7d346960$df9624c3@pal-s-omnibook> NNTP-Posting-Host: longford.cs.monash.edu.au X-Newsreader: slrn (0.9.4.3 UNIX) On 12 Oct 1999 09:48:56 GMT, pal wrote: >It seems that long file names are not supported by gcc for NY. Ie when I >write : >#include "longfilename.h" >a "file not found" error is produced; but the following works: >#include "longfi~1.h". >Until now I managed to stick with short file names, but I simply cannot >anymore [many files are automatically produced and need pretty explicit >names]. This is what you get for using a DOS port of gcc. (or, should I say, this is what you get as a result of Sony choosing to do so). You have three options, as I see it. 1) you can recompile cpp.exe to support long filenames. I don't know how difficult this would be, or where you'd get source, or indeed whether you could just use a win32 cpp.exe as a replacement. cpp is simply the C preprocessor. it takes a source file as input, and outputs the processed text. It's used in a pipeline, with the next stage being compilation. 2) You could compile gcc or egcs as a mips cross compiler for win32, and thus end up with a completely win32 kit, complete with much better compile times, no DPMI problems, and much better output code. This requires a bit of work, and also a copy of a native gcc compiler. have a look at www.cygnus.com if you're interested in this approach. I can help with building the cross compiler if need be, although the procedure's reasonably simple. 3) you could switch to linux, and never have to worry about long/short filenames ever again :) Toby.