[cairo] cairo.h in /usr/include

[Carl Worth]

On Sun, 05 Sep 2004 15:38:04 -0400, Owen Taylor wrote:
> Having cairo.h directly in $(includedir) might be problematical.
> It means you can't have parallel installs of two API incompatible
> versions.

OK. I'm willing to change this.

> When we went from GTK+-1.2 to GTK+-2.0, we had to release a new
> version of GTK+-1.2 and require people to install it so that
> we could have:
> 
>  $(includedir)/gtk-1.2/gtk/gtk.h
>  $(includedir)/gtk-2.0/gtk/gtk.h

There are a few things about how parallel install is sometimes
implemented that still bother me. Mostly it's just about inconsistent
naming practices. (These have annoyed me as a user on several
occasions with several packages, and are among the reasons I've
hesitated on moving to a "parallel installation" scheme.)

Picking on GTK+ for a moment just to demonstrate some of the issues:

* The directory under $(includedir) has "2.0" in its name regardless
  of whether it's version 2.0, 2.4, or 2.6 that happens to live
  there. These various versions are all API compatible so the
  directory name can't change, but it seems confusing to have it stuck
  at "2.0". Sticking to the minimal common portion of the version
  (eg. "2") seems appropriate.

* The pkgconfig file for GTK+ has yet a different name, "gtk+-2.0"
  rather than "gtk-2.0". But I think that's just because GTK+ has
  punctuation in its name, rather than due to anything regarding
  parallel installation.

* The package names for various distributions are yet different again:

	Fedora:		gtk2
	Debian:		libgtk2.0-0

  Of course, the distributions have their own naming conventions and
  there's only so much the upstream author can do to get consistency
  here. But it is interesting to note that in both cases the "-" has
  disappeared from the name.

The one thing that does seem clear is that avoiding a "-" in the name
can reduce a lot of these issues. This is in contrast to Havoc's
"Parallel Installation" guide:

	http://ometer.com/parallel.html

which suggests "-X" for almost everything.

So, I think I'd like to start with a name of "cairo1" and try to use
that wherever possible, (and just suck it up that the name is so much
less aesthetically pleasing than "cairo").

Also, I notice that following the example of many packages on my
current system would put include files in a directory such as:

	/usr/include/cairo1/cairo

rather than just:

	/usr/include/cairo1

Are there any good reasons for the former? If it's just to make the
user use:

	#include <cairo/cairo.h>

then I know I'll want to avoid that. I've never liked include
directives of that form anyway.

> Of course, moving cairo.h *out* of $(includedir) causes it's own
> problems. As I recall, for early versions of GTK+-2.0, we checked
> during 'make install' for $(includedir)/gtk/gtk.h and die with
> an error message.

I'm not too worried about that issue for now. We've been giving out
cairo with guarantees of instability so far. But a little guidance in
the Makefile that the user needs to clean things up certainly wouldn't
hurt.

> Of course, if you are never planning to make incompatible API/ABI
> changes to cairo after the initial stable release, than this doesn't
> matter.

I'd like to avoid these as much as possible, but I agree it makes
sense to plan now to make it easy when we do decide to do this.

-Carl