Synaptics: a number of issues with commit 39afe69ad7d2

[Dan Nicholson]

On Mon, Jun 13, 2011 at 4:44 PM, Gaetan Nadon <memsize at videotron.ca> wrote:
>
> Commit
> http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=39afe69ad7d2258d4043044d1283bd6e311e48da
>
> build: collapse all Makefile.am files into a single non-recursive one.
>
> With this change, the whole of the build is done non-recursively in the
> top-level Makefile.am.
> This reduces the amount of overhead due to recursing into directories only
> to build one file.
>
> has raised a number of issues. I have submitted patches for the easy ones,
> but there are some that I cannot figure out alone.

I would have to agree that if this came by the mailing list I would
have raised objections to it.

I think the biggest benefit you'd normally get from it is reducing the
number of convenience libraries of code in separate subdirectories
since you have to wait for libtool to relink them all the time. That
point it moot here since there's just a single module with no
convenience libraries.

Another typical benefit is waiting for make to fork itself repeatedly
to descend into subdirectories. I'd say unless you're building on arm
this is not a significant amount of build time nowadays.

The other nice benefit from using non-recursive make is that when
you've only dirtied a single file in your tree, you don't need to wait
for make to walk the whole tree to rebuild. A single toplevel make
process has all the dependency info in the toplevel Makefile. IMO,
unless you're getting to a project the size of the xserver, this is a
not a significant amount of time. And if you're trying to use
non-recursive automake on a project as large and diverse as the
xserver, it would probably be a nightmare.

On the other hand, I believe non-recursive make adds to the complexity
of the build rather than reducing it. With classic recursive automake,
it's very easy to divide and conquer tasks into subdirectories. Since
each Makefile is separate, you can tailor it specifically to what's
going on in that directory (e.g. creating manpages) and you don't have
to worry about variable or pathname collisions at all.

To have non-recursive make work, you need to constantly think about
how you're performing actions on files in sudirectories of where make
is operating. There's a lot more namespacing to think about since
everything's in a single file/process. Diego's own page shows some of
these issues:

http://www.flameeyes.eu/autotools-mythbuster/automake/nonrecursive.html

Another issue I can think of is when you need a pattern rule to
operate differently (e.g. use different flags) depending on the
target. We do this often with the documentation. In that case, you
either need to abandon the pattern rule and use a rule per-target, or
use a GNU makeism to set per-target variables. Typically you can just
setup the pattern rule per Makefile and not have to worry about
applying the wrong settings to the wrong target.

IMO, the benefits of non-recursive automake do not significantly
outweigh the added complexity.

--
Dan