Re: A Gtk's build system ?

[Sam Spilsbury <smspillaz gmail com>]

(Replying out of order, apologies in advance)

On Tue, Aug 5, 2014 at 9:42 PM, Emmanuele Bassi <ebassi gmail com> wrote:

the GNOME Builder talk at GUADEC also presented autotools integration
that was based on convention and would simplify creating and
maintaining autotools-based projects, using "fig"[1] as a prototype.

Fig looks quite useful for maintaining applications and libraries which don't care about the build-system (the majority). Build systems generally are annoying to write if you don't care about them. Autotools especially has conventions that are just not intuitive at all if you have little experience working with it[*].

I suspect that for those developers who might be frustrated by Autotools' gotchas and syntax in these situations, fig is the right tool to use here.

all this stuff can be solved by conventions, macros, and templates.

Having written a few macros, templates and other bits of autoconf/automake, I can assure the list that when faced with a situation where you have to do this, it is not easy to do. If we want to integrate more tooling into our build-systems on top of what we already have, this problem needs to be solved. Right now, there is a very clear disincentive to writing build-tooling to integrate with the build system.

I don't mean to simply post a laundry-list of things that are annoying about Autotools, but I do wish to share some examples which demonstrate this problem. 

There are many trivial situations where Autoconf will generate an invalid configure script instead of reporting an error. Leaving a space between a template instantiation and a bracket is a common pet-peeve of mine. Problems like these are difficult to chase down and a waste of developer time.

Another part of writing an Autotools based build-system is that you need to write Makefile templates by-hand in order to generate new files or build rules. There are very subtle differences between what is valid /make/ code and what is valid /automake/ code. Text can only be substituted into a Makefile once, which also limits the kinds of rules that you can generate.

This all depends on priorities of course. As was suggested there will be a clear trade-off between moving away from what satisfies the constraints of portability, cross-compilation and distribution[+] we have at present and potentially gaining a simpler system for writing new build-system code.

Sam.

[*] I note that this is a problem with most build systems and their various DSL's. CMake for instance has some non-intuitive variable scoping rules.

[+] These problems are solvable with other build-systems, such as CMake, in my experience, however they will require some new CMake modules to be written.

--
Sam Spilsbury