[cairo] Re : internal cairo include syntax seems not flexible enough, backward-compatible fix proposal.

[Carl Worth]

On Wed, 2008-09-24 at 08:00 +0000, Fabien Costantini wrote:
> >3. It breaks our standard build instructions. The documented approach
is
> >to use pkg-config to get the correct build flags. But if pkg-config
is
> >giving you -I/some/prefix/cairo and you use <cairo/cairo.h> then you
> >won't get the header you want from /some/prefix/cairo, but could
> >silently get an incorrect one from /usr/include/cairo. That's very
bad.
> I guess many muti-platform oriented teams would think that forcing
> a pkg-config dependency in their build files is indeed very bad.

I didn't explain this very well at all.

It has nothing to do with forcing a pkg-config dependency. The problem
is that if one *does* use pkg-config, then using <cairo/cairo.h> in your
application can lead to hard-to-debug failures in some cases. And that's
bad.

In fact, the problem isn't unique to people using pkg-config. For
example, I frequently find myself compiling code to different prefixes,
(/usr, /usr/local, /opt/cairo-1.6.4, etc.). And I find myself wanting to
mix and match various pieces at various times for debugging.

This works fine by passing the explicit paths to the compiler, (such as
-I/opt/cairo-1.6.4/cairo), but *only* if my source files include
<cairo.h>. As soon as my source starts including <cairo/cairo.h> then
I'll start getting the first cairo/cairo.h that the compiler finds along
its search path.

Basically, you're just giving up control that way.

> >So we definitely want to teach people to just use <cairo.h>. 
> Open source for me rimes with open minded, 
> I believe that one could recommend one include construction,
> but not force it.

Fair enough. We won't try to force the approach, but we will continue to
teach <cairo.h> and reserve the right to scoff just a little if we ever
see <cairo/cairo.h>. Fair enough? :-)

-Carl