It's actually the case that the filenames are just fine. It is legal to use a pathname of any length on the Mac, but no one does. You can explicitly open a file with the name:
"\pMacintosh HD:Folder Name:Another Folder Name:A Long File Name.h" the MacOS will handle this just fine. But not codewarrior. The fact that the #include names with long paths breaks is actually a bug in codewarrior, not a limitation of the MacOS. I think they're assuming that the maximum file name length is the maximum path name length, but because it can include directory components, it can get longer. Removing the "util/" from the #include lines fixes the problem for me without changing the filename, but would break the build for everyone else. Having #include lines with paths in them is an explicitly nonportable construct but changing that would be a pain for everyone, so I'm not suggesting we do that. A reasonable compromise would be to workaround the codewarrior bug by shorting the whole path length by shortening the file names, but it's important to understand this really is a bug - codewarrior should be able to handle this. I've been discussing this with Ron Leichty at Metrowerks, who is remarkably helpful - [EMAIL PROTECTED] Mike Crawford [EMAIL PROTECTED] > > > Did you mean to write more? :-) > > Well, actually, I _did_ write more... and it came through fine on the copy of > the message the list sent to me. Must be the backslash on the end of the one > quoteback line that's cause havoc. > > In any case, I did some testing and realized that some odd filename > translation > is going on. When Metrowerks has to add a second layer (Unix dir -> Mac dir), > the filename itself doesn't get translated. But the bottom line is that two > files in Xerces' util directory have names that are too long for the Mac's > current file system. > > > > --Bill >
