On Monday 24 Feb 03, David Starks-Browning writes: > ... > Unfortunately, I just found a possible "showstopper" with a Cygwin > build. Because Windows is case-insensitive with filenames, gcc finds > plucker/viewer/font.h to satisfy > > #include <Font.h> > > instead of Core/System/Font.h from the SDK. This breaks the viewer > build, of course.
Phew! Never mind! This is no problem after all!
Cygwin users can set the CYGWIN environment variable to "check_case:strict" and gcc will act properly.
<rant>
That's a decent solution because it doesn't require changing any code, but I do get frustrated by the assumptions made so often in open-source code that you couldn't get away with in a professional development environment (outside, perhaps, of a lowball Windows shop.)
In such an environment, it would be understood that plucker/viewer shouldn't be in the include path. That's a project file; inclusions of it would look something like:
#include "../viewer/font.h"
while core system files are obviously in the include path, and thus the intended inclusion would be:
#include <Font.h>
Of course Linux/Unix purists will make the claim that a "real" operating system (i.e. one with little market share but with case-sensitivity) wouldn't have this problem, but that's not true even then... I develop for quite a few platforms, each with a wide variety of other libraries and classes I may include. It's quite normal to have several inclusions with the same filename but different locations in a project, and that's often outside of your control completely.
</rant>
_______________________________________________ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
