[cairo] Re : internal cairo include syntax seems not flexible enough, backward-compatible fix proposal.
Carl Worth
cworth at cworth.org
Wed Sep 24 12:07:32 PDT 2008
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
More information about the cairo
mailing list