[Fwd: Re: [cairo] Rethinking cairo's build system]

Tue Jun 20 20:25:46 PDT 2006

I sent this previously but didn't make it to the list.

-------- Forwarded Message --------
From: Behdad Esfahbod <behdad at cs.toronto.edu>
To: Carl Worth <cworth at cworth.org>
Cc: cairo at cairographics.org, Hans Breuer <hans at breuer.org>
Subject: Re: [cairo] Rethinking cairo's build system
Date: Mon, 19 Jun 2006 11:36:46 -0400

On Fri, 2006-06-16 at 18:51 -0400, Carl Worth wrote:
> So there are a number of issues that have been annoying me about
> cairo's build system lately. Many of these are due to the fact that
> I've been taking advantage of git-bisect a bunch lately, (and with
> great results!) and doing that magnifies bugs in the build system that
> cause it to take longer than it should.
> 
> So here is a laundry list of some of the annoyances:
> 
> 1) Running automake and configure take too long

Use --cache-file configure option.  I've even written the backend check
macro such that the result of entire backend checks is cached, although
that may not be working correctly (losing CFLAGS and LIBS when using
cache.)  Let me know if that's the case and I'll fix it.

> 2) Whenever configure is run, every source file is rebuilt

This is as you already said because cairo-features.h is generated
unconditionally.  I'm fixing it right now.

> 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".

Already fixed these.  Just replaced noinst_PROGRAMS with check_PROGRAMS.

> 4) Building the docs takes too long, (or perhaps it just needs to be
>    moved to "make doc" instead of "make)

Will look into it.

> 5) Building the docs touches tons of files, requiring a "git
>    update-index --refresh" before "git diff" output is clean again.

gtk-doc can be taught to not do this.  Will follow up.

> 6) Building the docs modifies (!) a bunch of files under version
>    control. This is worse than annoying.

IIRC there's new gtk-doc options that fix this.  Will investigate post
1.2

> 7) The "make check" target should generate the html report
>    unconditionally, rather than requiring a separate "make html".

Does it help if I rename it to "make test"?  More specifically, make
"make test" clean all .log files, run tests, and generate report?

> 8) Running "make check" takes an annoying amount of time because every
>    individual test is re-linked whenever there is any change in the
>    library. ("make check" also takes too long because many of the
>    tests are much larger than they really need to be).

This is a bit hard to fix.  I'll look into it.

> 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.

I fixed that last week if you remember.  CAIRO_TEST_TARGET=image,xlib
works now, as well as CAIRO_TEST_TARGET="image glitz", to give you
examples.

> 10) With the test suite we can run all tests (with "make check") or
>     any single test (by executing it directly), but it would be great
>     to be able to run a subset of tests.

Make and automake already support that:

  make check TESTS="device-offset device-offset-positive"

Moreover, you can pass CAIRO_TEST_TARGET on the cmdline too:

  make check TESTS="device-offset device-offset-positive" CAIRO_TEST_TARGET=image,xlib

>  In particular, I would like
>     something like "make recheck" that would run only the tests that
>     failed on the last run.

  This is particularly easy to implement.  Will do.  Just let me know
the exact behavior you want.  Do you it to test all tests failed in the
last "make check" or the ones in last "make [re]check"?

> 11) The build system isn't deemed adequate by many win32 developers,
>     many of whom end up hand-coding something.

But as long as most of the development happens on Linux, I don't think
that's a big deal.  Hans and Tor have been packaging all kind of
libraries in GNOME and its dependencies and I don't think cairo is the
most problematic one.

> And there are a number of other things, (many general complaints could
> be made about things libtool and its pernicious .la files that do
> nothing but harm on Linux based systems for example).

True, but you really don't want to deal with bug reports coming from not
using libtool.  Note that NO other tool can replace libtool.  All the
other systems at best replace automake/make only, and are not installed
commonly, incomplete, and untested at best.  I think moving to git was
enough of making barriers for cairo development :), at least many of us
know exactly how autofoo works, and can hack around most of its
problems.  I prefer not forcing any change into users.

> So there's a real smattering of issues above. Some of them might have
> simple, isolated fixes (and if so, pleas contribute them!). While
> others will requiring larger changes (upstream gtk-doc changes? moving
> documentation to another system?).

Seems like using latest gtk-doc and filing a request to them is all that
remains.  And the relinking issue that I'll follow up with libtool
maintainers.

> One of the larger changes I think we'll definitely do is to just write
> our own little program for running the test suite rather than using
> what's generated by the TESTS variable through automake. This seems
> like the easiest plan for hitting #7 and #10 above.

We've been doing that in other projects, and I don't really like it, and
#7 and #10 above are already solved/solvable.  That program should be a
shell script though, not a big binary linking all tests as tests may
crash.

> And if we do that, then it looks like there are a large number of the
> above that could be addressed by moving away from our current
> autotools setup, (which is likely a requirement for getting #11). I'm
> not sure that we want to do that, but I'm certainly open to doing it
> if it will help us address several of the issues above while not
> causing new problems.
>
> One thing I've been wanting to look at closer for quite some time is
> cmake (http://www.cmake.org). Hans Breuer tried cmake out for building
> cairo with MSVC a little over a year ago and was very pleased with
> it. I've also recently heard that Scribus is using cmake with good
> success.

Ranted above already :).  But I think several of the issues above are
already solved anyway.

> Anyway, that's just a note to let people start thinking about this or
> experimenting with things. I don't plan to actually try anything in
> this area until after 1.2 is done.
>
> -Carl

Let me know if you have other issues with the build system and I will be
happy to look into them.

-- 
behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
        -- Dan Bern, "New American Language"
-------------- 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/20060620/a3a38fe2/attachment.pgp