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

[Carl Worth]

On Thu, 01 Sep 2005 10:50:40 -0400, Owen Taylor wrote:
> I don't think this is typical. And stuff that is *only* compile time
> doesn't have to appear in the public headers. The public header
> would have something like:
> 
> #ifndef CAIRO_DECLARE
> #define CAIRO_DECLARE(r) r
> #endif

OK. If we have only unconditional, empty macro definitions like this,
I definitely can't argue that we're pushing much fragility out through
the public interface.

It would certainly help appease my grumpiness if the macro setup were
no more complicated than the above. Stuart, would that be adequate for
you? You said you had a patch for all this, but I haven't actually
seen it yet.

> In the end, virtually all libraries that are widely used cross-platform
> do decorate their headers. libxml, FreeType, apr, libpng, zlib,
> so forth and so on. We get away with not decorating the GTK+ headers,
> but I don't think anybody would consider the GTK+ stack simple to
> get building on Windows, especially when not using automake.
...
> What I was hearing from the Mozilla people was not "we dislike .defs
> files" but "we want this to be the same as all the other pieces
> of code that we deal with, so we can just drop it into our build
> system". I don't think adding sed scripts to the build process is
> going to achieve that.

Alright. It seems clear that I'm the holdout here, and the heroic
efforts I'm attempting to save header-file cleanliness aren't
working. I'll let this one die.

So, now I'll amend my previous list of criteria:

"does not require maintainers to maintain any attributes"

    I'll drop this requirement. We're now API stable so adding public
    functions is rare enough that this shouldn't be too hard to get
    right. I mean, I do have to remember that trailing semicolon for
    every prototype, so maybe I can remember some export tag too...

"presents the attributes to the compiler when compiling cairo"

    Obviously, this is a requirement of any solution. No change here.

"does not present any attributes (or even ugly empty-defined macros)
in installed header files when not needed"

    I'm willing to concede empty-defined macros in the public header
    file. (Since we've got that much, we might just as well allow
    non-empty macros _if_ there's no other choice---which so far
    sounds like OS/2 only if I've understood things correctly).

If I can retain one style point, I would still prefer non-
parameterized macros. I don't want function return types to be inside
of parentheses.

I don't know if I'll play the whitespace games I proposed earlier or
not. They might be a bad idea. But my impression is that I'm the only
person who ever cared about that anyway, so it's probably not even a
matter meriting any discussion here anyway. ("Just let crazy old Carl
arrange that file however he sees best...")

OK. That's far more than enough talk on this subject. Let's see a
patch, get it into CVS, and move on. (And yes, I do realize that I'm
the one to blame for dragging this out so much.)

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050901/fb2b2aff/attachment-0001.pgp