[cairo] Re: Munging header files for export (and other) attributes

[Owen Taylor]

On Tue, 2005-08-30 at 10:47 -0700, Carl Worth wrote:
> On Tue, 30 Aug 2005 12:40:08 +0200, Doodle wrote:
> > Carl Worth wrote:
> > I wouldn't like to be a troll but I don't see why a header file has to
> > be so much readable.
> 
> A perhaps more significant objection that I have is that I really
> think the published interface for cairo should be standard C. I think
> it's very wise to avoid putting compiler-specific directives in the
> installed header files if we can avoid it.

Because? There are clearly some compiler-specific directives that
are very useful for public header files. 

For example, something like:

          int
          my_printf (void *my_object, const char *my_format, ...)
                __attribute__ ((format (printf, 2, 3)));

When hidden with appropriate macros and #ifdef __GNUC__.

> > I think the first one is better, because there is a slight possibility
> > in the second that if the compilation is interrupted, then some header
> > files will remain modified, some unmodified.
> 
> Yeah, but the first option was pretty broken too as it required
> mucking with a bunch of files in a way that made them aware of this
> mess.

The whole idea of using generated header files introduces a disturbing
degree of fragility into the build system. Speaking from experience,
build fragility is bad: it wastes time, it keeps people from getting
the software built, it discourages contributions; you can't hack on
a project unless you can build it from source. Give me a nice solid
segfault any day.

It should also be pointed out that the primary audience we are trying
to address with this are people who *aren't* using cairo's standard
build system: they are people who are integrating cairo into the Mozilla
build  system, creating project files for MSVC, hand-crafting Makefiles
for OpenWatcom... so hiding behind a tested set of rules in a
Makefile.am isn't satisfactory.

Even if we distribute the generated files in a tarball, we still
haven't really addressed the problem; we want contributors using
other compilers to be able to work from CVS as well.

> I really should get in the habit of setting aside late night emails so
> I can re-read them in the morning and throw out all the stupid ideas
> before sending them out.
> 
> Anyway, here's another approach. How about putting the munged header
> files in a separate directory, but with the original filenames. Then
> new, initial -I option while compiling cairo would let the munged
> headers be found.

Having two separate copies of the header in different directories with
the same name, sounds like a recipe for all sorts of wonderfully
difficult to debug build problems.

If header cleanliness is a primary consideration, then there is an
argument for not trying to address these problems at all; .defs
files do work on Windows; OS/2 is a marginal platform these days.
But if you are going to address the problem, there is a stronger
argument for addressing them in a way that “just works” — and I'm
not convinced that a header-munging scheme is going to just work.

Regards,
					Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050831/c28119fe/attachment-0001.pgp