[PD] autotools

Dan Wilcox danomatika at gmail.com
Sun Dec 3 03:58:17 CET 2017


I started working on the pd autotools build mainly because I had already used autotools before and it seemed like the easiest way to get Pd to build on macOS again. So far, we've moved forward with it in general, but at this point I wonder if a re-examination makes sense.

Some points:

1. ./configure && make are great for users -> The more people who can easily build Pd, the more help we can get for all sorts of things. I think we've been seeing that the last 6 months or so.

2. Built-in support for gettext processing, standard install targets, etc allow for translations and package management (Debian)

3. *Maintaining* the configure.ac & Makefile.am files makes maintaining the build system relatively easy, if you understand it (see next point).

4. *Developing* the autotools build system is a PITA. There are a lot of details and basic understanding required in order to both make sense and use it effectively. Once everything works, it's *great* (point 1), but sometimes getting there takes a while. Also, fewer people are willing to help with it because of the overhead.

Pd is in some ways both a simple and a complex project to build. Simple in that C is easy to build anywhere and TCL just needs things in the right place. It's complex in that Pd builds and runs on a variety of platforms, each with it's own peculiarities.

The original makefile build system works relatively well for the simple cases while the autotools build system works for the complexities (while requiring complexity). The makefiles are straightforward and easy to understand at a loss in flexibility while ./configure et al are black boxes that support lots of configuration options and hopefully work most of the time.

When I did the overhaul last year, I went through and added documentation to the various Makefile.ams and the configure.ac  to help in understanding things, but I think that it's still down to IOhannes and I to do any sort of work on the setup as it is. I'm not sure if that is healthy in the long run.

I'm thinking now about about different approaches to simplify what is there:

1. non-recursive automake: a single large Makefile.am without the various files in subfolders. There are a number of advantages to this including build speed, putting things in one place, etc.

2. hybrid autoconf/makefile: If we want, we can use regular makefile rules in automake files or our own makefiles instead of automake and simply use the configuration variables for autoconf. This would allow for exposing more of the core build information in a readable way at the expense of perhaps higher maintenance.

The autotools are definitely useful but I admit can be a bit of a beast (but this guide helps a great deal: https://autotools.io/index.html <https://autotools.io/index.html>). OTOH I would argue that *any* build system can be a beast, especially for a cross-platform project. In either case, I don't think we want to end up with a "non-understandable black box mess" and I'm thinking of ways to make things easy to work with for both Pd users *and* developers.

--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20171203/ea435e85/attachment-0001.html>


More information about the Pd-list mailing list