[cairo] Rethinking cairo's build system

[Carl Worth]

On Fri, 16 Jun 2006 18:07:07 -0700, "Vladimir Vukicevic" wrote:
>
> > 2) Whenever configure is run, every source file is rebuilt
> 
> True, but how often do you re-run configure?

"A lot". I haven't spent a lot of time looking into all the causes,
but every time I've spent time with "git bisect" it seems I always
rebuilding everything even when I know only a few files have changed.

Yevgen Muntyan has traced some of this problem down to the
cairo-features.h being unconditionally generated with every run of
configure so there's some hope this will be fixed soon:

	https://bugs.freedesktop.org/show_bug.cgi?id=7234

> > 3) An empty-target "make" command builds some utility programs in the
> >    test directory. These are problematic since they have more
> >    dependencies than cairo itself, (even circular dependencies). These
> >    need to be delayed until "make check".
> 
> This can be fixed by reworking the test directory.

Anyone know an "automake way" of doing this? We get all of our "make
check" behavior by just setting a TESTS variable. Is there a good way
to make those tests also depend on some other programs? It might be
easier to fix this after abandoning the automake-generated aspects of
the test suite as hinted at before.

> > 5) Building the docs touches tons of files, requiring a "git
> >    update-index --refresh" before "git diff" output is clean again.
> 
> This won't be solved by an upgrade to make; it's the fault of gtk-doc,
> I believe.

Yes it is. I didn't mean to suggest that all of my rant would be
solved by switching from the autotools. I was just getting all my
complaints out at once.

I'm told that with recent versions of gtk-doc it's possible to
eliminate the use of the problematic "templates" all together. So
hopefully we can figure out how to do that.

> You could switch to an alternate documentation format, or
> just do what we (mozilla) are doing, and throw all your docs on a
> wiki.  The number of API reference pages would be small enough that
> they could be pulled down in HTML format and packaged together pretty
> easily.

One documentation system I'm thinking about is AsciiDoc:

	http://www.methods.co.nz/asciidoc/

> > 9) For "make check" we can test all backends (by default) or a single
> >    backend (with CAIRO_TEST_TARGET), but it would be nice to be able
> >    to test any subset of backends.

Behdad was kind enough to add this support already. Many thanks!

> I would suggest linking all the tests into one test binary that can
> run them all -- this would mean one relink instead of N, and would
> also give you better control over which tests to run on what targets
> etc.

Yes, that's what I think we'll end up doing.

> There are only two solutions to this; one is to provide Visual Studio
> project files (preferred), the other is to provide NMAKE-compatible
> makefiles.  I have the latter done, I just need to commit them --
> cairo is just built with the standard win32 font and surface backends.
>  PDF/PS/ft/etc. are not built, due to the freetype dependency (if they
> have freetype installed, they can probably run autoconf from
> cygwin).

Oh, speaking of which---that dependency sounds like a bad bug then. I
really don't like the idea of people not getting the PDF
backend---it's something that should be stock-standard just like the
image backend.

I *think* that when we just had the type3 font support that it should
have worked just fine on win32 without freetype. So it would appear
that it was the addition of the truetype and type1 font subsetting
that made freetype a hard dependency. So what should be done here is
to add win32 implementations of the freetype-specific stuff used in
cairo-font-subset.c, and put this stuff behind the existing
abstractions in things like cairo-scaled-font.c.

An interim approach, (that might be easier for someone who doesn't do
win32 stuff), would be to make all usage of cairo-font-subset.c be
conditionally compiled so that a win32 build would be functional
without freetype, (and that it would just drop back to always using
type3 fonts). That's less desirable, of course, but it might be a
quicker fix.

> There are a bunch of alternative build systems that all solve many of
> make's faults -- cmake, SCons, jam.  The all have their own problems,
> though, not the least of which is that they're not present on pretty
> much any system.  One of the first barriers that someone will hit when
> they want to play with it is that they'll be required to download
> another tool for actually building it, and this could easily throw off
> lots of people.

Yes, that's a good point.

So, anyway, I'm still interested in help on several of the above,
(even without switching the tools used to build). Several of the
"should be fixable" things Vlad mentioned I actually tried to address
(to some extent) and didn't succeed at. So any help in these areas
would be appreciated.

-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/20060619/7276e47b/attachment.pgp