At 10:23 AM 2/25/2003 +0000, David Starks-Browning wrote:
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

Reply via email to