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

[Stuart Parmenter]

On 8/31/05, Carl Worth <cworth at cworth.org> wrote:
> On Wed, 31 Aug 2005 09:47:51 -0400, Owen Taylor wrote:
> I agree on the general "build fragility is bad" point. And that's
> exactly why I don't want a lot of #ifdefs in cairo's public header
> files. Pushing fragility out onto users of cairo is much worse than
> absorbing it within the build of cairo itself.
> 
> > 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.
> 
> There's a legitimate concern here, certainly. But I'm not sure I'm
> drawing the same conclusion from it that you are.
> 
> One of the benefits I mentioned in the header-munging proposal was
> that the sed-magic would be run by all parties, whether or not any
> annotations were necessary. So, we could have better testing with this
> approach than one in which only a small subset of people compiling
> cairo do some header-file processing, (as is the case with the current
> cairo.def rule).
> 
Getting sed to actually run on all parties in all build systems
everywhere I don't think is feasable.  If people are going to use MSVC
projects, for example, they may very well not have sed installed on
their machine or available to use.  In the Mozilla case, we could
potentially do this, but I think having everyone who wants to build
cairo just have the right file with the right info in it is the way to
go.  Requiring that people mark new public functions in cairo.h seems
_signifigantly_ less fragile than any other method proposed so far.

> As for the fact that some people are using other build systems. We
> can't prevent that, but well-tested pieces of Makefile rules could
> still be used elsewhere, (or even placed in scripts external to the
> Makefiles if that would help).
> 
> The other thing we can do is to try to improve our build system to
> eliminate some reasons that people avoid it, (though I don't expect to
> ever be entirely successful on that front).
> 
Without dropping libtool and writing your own system, I don't think
you're going to have much success here.  Even if you did that though,
I would expect some people to want to build cairo outside of that
system.  It isn't clear that we would want to use your makefiles even
if we could, as we want to build and link in in varying ways depending
on how you build Mozilla that would be difficult to do without
expanding the cairo build system even more.


> > 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.
> 
> I agree it's not a perfect solution, but it's what I've been able to
> come up with so far.
> 
> > 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.
> 
> I think I replied to this in more detail already in my reply to John
> Ellson down-thread.
> 
> We do have a start at a .def approach in the tree, but it was not
> getting pick-up from some Mozilla people who started proposing more
> header-file decoration. I'm just trying to find a solution that
> everyone is willing to live with.

def files are a bad solution for us.  We would need them for every
compiler and platform that we support.  We build with visibility
hidden by default on gcc (when available), so none of the symbols get
exported for us on Linux either.  Marking them in cairo.h solves this
problem for us on _all_ platforms, doesn't require _any_ build system
hacks which we have to keep in sync between the mounting number of
different build solutions, and actually tells people reading cairo.h
that stuff is exported from the library and how.  I see these things
as huge wins and to me they drastically overshadow a "want to keep the
header clean" argument.

-stuart