[Mesa-dev] [RFC] Convert mesa to automake/libtool

[Ben Gamari]

On Tue, 4 May 2010 16:48:10 -0700, Dan Nicholson <dbn.lists at gmail.com> wrote:
> On Tue, May 4, 2010 at 5:34 AM, Ben Gamari <bgamari.foss at gmail.com> wrote:
> > <Uninformed rambling>
> >
> > Hey all,
> >
> > As a casual follower of Mesa, I too have been bitten bad builds on more than a
> > few occassions. That being said, Autotools makes me cringe and certainly makes
> > the build system less transparent to the end user. It seems that there is an
> > assumption that there exists only two options underlying this discussion:
> > Automakes, or what we have. I'm quite surprised that nobody has considered the
> > possibility of adopting a standard non-recursive makefile structure, as is used
> > in, say, Keith Packard's notmuch[1] project.
> 
> 1. Mesa is already basically doing this, but just in a poor way
> because everything has to be reimplemented since it's rolling it's own
> build system instead of leveraging an existing, supported one.
> 
As far as I can tell, mesa's build system relies pretty heavily on
recursion.

> 2. The scope of the mesa project and the number of optional pieces
> blows notmuch out of the water. If this were a small project, I might
> agree, but the main reason we've gotten to this point is because mesa
> has outgrown it's hand rolled system.
> 
I definitely agree about the scope of the project. The complexity and
scale of mesa is orders of magnitude greater than that of notmuch.

> I can only think of one mainstream project that uses GNU Make
> exclusively with consistently good results, and that's the linux
> kernel. And the reason why is because they have a maintainer (H. Peter
> Anvin) dedicated to the Kbuild system. As one of the people who has
> spent time maintaining the mesa build system, I can tell you that it
> is not nearly of that quality level.

This is quite true. Kbuild is excellent, but I completely understand
that mesa doesn't have the manpower (or need) to put that much effort
into its build system.

At this point, I'd agree that autotools (despite my severe dislike) is
probably the best option.

> [snip]
> 
> However, if the automake plan is nak'd, purely GNU make with all the
> features would be my next suggestion.

Good, I'm glad to hear this. Despite the large number of platforms that
mesa must build on, I don't think GNU make is all that much to ask.

> Mesa is currently supposed to be using portable make features. Like I
> said, this would be my next suggestion, though.
> 
> > > [snip]
> > > 
> > There's no reason why libtool requires autotools. This could be easily
> > integrated into a custom build system if need be.
> 
> Have you ever actually seen anyone do that? I know of one project
> (libacl/libattr), and it was broken in a lot of ways. It's even
> discouraged by upstream.
> 
Nope, never have. We considered using it in notmuch, but ended up just
driving gcc ourselves. It's worked so far, but notmuch hasn't seen
nearly as many odd/broken platforms as mesa.

>
> >> * Consistency in build commands for free from automake. Right now we
> >> have the compiling and linking commands repeated throughout the tree
> >> and they're typically out of sync. I've tried to keep them in sync
> >> before and it was a lot of effort. With automake all you really need
> >> to do is tell it the CFLAGS and LIBS to use and it'll take care of the
> >> rest.
> >
> > This should be completely solved using a non-recursive build system, where make
> > knows all build dependencies.
> 
> What does a non-recursive make system have to do with it? How do I get
> consistent usage of commands and flags from a non-recursive build?
> 
Somehow I originally interpretting the above quote to mean handling
dependencies correctly to maintain build consistency. Reading through it
again, it's clear that non-recursive make has no bearing on the original
statement. That being said, a good set of pattern rules and
target-specific variables make it trivial to get consistency in build
commands with gnumake.

- Ben