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

[Dan Nicholson]

On Tue, May 4, 2010 at 5:34 AM, Ben Gamari <bgamari.foss at gmail.com> wrote:
> On Sun, May 2, 2010 at 12:46 PM, Dan Nicholson <dbn.lists at gmail.com> wrote:
>> Brian,
>>
>> I'm putting forward this request completely understanding your
>> position why you don't want automake and libtool in your project.
>> However, I think that mesa has outgrown the static Makefiles approach
>> for a number of reasons. For a project that's grown to the complexity
>> of mesa, I believe you need something that is more flexible and robust
>> than the current system can provide. Eric (and I think Corbin, too)
>> has a branch adding automake and libtool to the mesa repo.
>>
>>  http://cgit.freedesktop.org/~anholt/mesa/log/?h=automake
>>
>> I haven't looked at it in detail, but I know Eric knows what he's
>> doing as he's maintained many of the autotooled xorg modules. Here are
>> some of the pros and cons I see to making this change.
>>
>
> <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.

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 recently reworked the build system of an internal piece of scientific
> computing software with a notmuch-inspired makefile structure and the results
> have been fantastic. The build is much faster, the makefiles are clearer (in
> most cases nothing more than lists of rules), and the build integrity is
> guaranteed (up to the quality of the prerequisite lists). Moreover, I was quite
> surprised by how well suited Make was to this style of build system. When one
> adds a few features of GNU Make (per-target variables), the result is quite
> impressive.

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.

The last project I played around with that had a hand-rolled system
was libdvdread. The way it worked was that things would break and then
they would be reimplemented exactly as the autotools did it. And
that's what I end up doing when I fix mesa build bugs. I spend a bunch
of time figuring out where things went wrong and then I fix them just
like automake would do it because they already solved that problem
years ago.

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

>> Pros:
>> * AM_CONDITIONAL provides a clean way to separate optional parts of
>> the build. The way that optional components are handled right now is
>> pretty fragile and basically amounts to having lists of subdirectories
>> being correct in the config file.
>
> I don't see what's wrong with the ifdef directive. This seems like the right
> way to deal with this in fact.

Mesa is currently supposed to be using portable make features. Like I
said, this would be my next suggestion, though.

>> * For all mklib's simplicity, it is inconsistent between platforms,
>> doesn't handle errors and provides only a scant amount of the features
>> that libtool does. Libtool provides a robust and well tested means to
>> generate libraries that handles nearly all the gory details about
>> generating working binaries on many platforms. I don't think anyone
>> working on mklib can claim to have the same type of knowledge about
>> platforms and toolchains as the libtool developers.
>
> 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.

http://www.gnu.org/software/libtool/manual/libtool.html#Makefile-rules

>> * 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?

--
Dan