On Wed, Dec 10, 2003 at 08:47:11PM +0100, Grzegorz Nieweglowski wrote: >>>"(...) If the directory dir is a standard system include directory, the >>>option (this means -I) is ignored" >> >> Do the gcc people give a reason for not allowing a system directory to >> be "blessed" with -I? > >I wouldn't call it a "reason", but the manual puts it like this: > >"(...) the option is ignored to ensure that the default search order for >system directories and the special treatment of system headers are not >defeated".
OK, I see. This is to prevent system directories being searched before directories containing gcc-specific replacements for system headers. >> There is no ft2build.h in the xc/lib/font/FreeType directory in >> 4.3.99.901 (it got moved to the only place that uses it: >> xc/lib/font/FreeType/module). That's why I asked if your 4.3.99.901 >> source was "clean" :-) I did see this problem myself before moving >> it. > >But... but my tree is clean. It just isn't a "pure" 4.3.99.901 tarball, >because some time ago I've downloaded 4.3.99.14 and then gradually >patched it up. But all I did was unpack the archive, apply the newest >patch and repack it. I tried not to break anything, really :) > >I know that not all changes can be registered by diff (and reproduced by >patch) but I expected it only to affect non-textual files, like >some images or maybe binary fonts. Diff&patch are pretty reliable when >it comes to creating/removing text files, at least that's my impression. Yes, it is. Back before XFree86 had wide CVS access, all updates were distributed as patches, and it worked pretty well. >But I guess you'd need to use the '-N' diff option to get that behavior >(at least with GNU diff), and the official patches don't do that, they >only use "-u". Is the -N something available only with some special >versions of diff? Or would it be possible to generate future patches >with -uN ? If you look through the 4.3.99.15-1.3.99.16 patch, you'll find the patch hunk that removes xc/lib/font/FreeType/ft2build.h. I don't know why it didn't happen for you. >> If there's a reliable way of knowing when to include <FlexLexer.h>, >> then we probably should include it. > >I've just noticed that my FlexLexer.h requires iostream and maybe some >more C++ parts. Maybe that was the reason for merging parts of it into >twm - to avoid the dependencies on a C++ compiler? If you would include >this header, you would probably need something like g++ to compile twm. >Not very nice, is it now. So maybe it would be easier to just play along >and keep it the way it is now... just patch twm up a bit so that it >compiles with older and newer flex releases... Would my, ekhm, "patch" >cause trouble with older flex versions? I don't see any problem with your patch. I was just wondering if there might be a flex-supplied header that could be used to avoid these repeated updates. It looks like FlexLexer.h isn't it if it requires C++. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
