On Tuesday 25 Feb 03, Fringe Ryder writes:
> 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>
In fact simply
#include "font.h"
is correct because that's where font.h lives w.r.t. viewer.c.
One could ask whether the GCC option "-I<srcdir>/viewer" is
appropriate. This deliberately puts <srcdir>/viewer ahead of the
default system include paths when satisfying <...> include directives.
That's what led gcc to load plucker's own "font.h" rather than the
SDK's Font.h when satisfying a <Font.h> include directive in another
SDK header file. (And this only happened because the Cygwin gcc was
configured to ignore case.)
In any GNU autoconf-based package I've ever built, the
-I<srcdir>/... directives have always been there, and developers had
to be careful not to use there own versions of (presumably well-known)
system headers. Unless, they intended to (why -I<dir> works as it does).
It didn't occur to me that the -I compiler options were superfluous if
#include "path/to/projectheader.h"
was the correct path relative to the source file including it.
Interesting!
Anyway, ...
Indeed, the Plucker Team has ignored the possibility to build plucker
on Windows. Who cares? Despite that oversite, it can be done now,
thanks to Cygwin. (That's why Cygwin exists!) Moreover, it's
entirely possible that if header-file-naming was the only impediment
to a Cygwin build, then they might have made the necessary changes.
So I don't think the Plucker Team should be criticized for this issue.
My 20p.
Regards,
David
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
