Synaptics: a number of issues with commit 39afe69ad7d2

[Daniel Stone]

Hi,

On Tue, Jun 14, 2011 at 09:26:13AM -0700, Dan Nicholson wrote:
> On Mon, Jun 13, 2011 at 4:44 PM, Gaetan Nadon <memsize at videotron.ca> wrote:
> > 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.

Same here.

> 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.

Right.  Even on ARM, it's not exactly a bottleneck, since the
compilation takes long enough that running make is hardly a profile
hotspot.  And even then, only so if you're rebuilding
xf86-input-synaptics in a tight loop.

> 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.

It would, but it would make builds fast enough that it might, _might_ be
worth a go there.  It would mean a lot more care and feeding of our poor
build system though, and would be a fair bit of work.

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

At least for xf86-input-synaptics, I agree.  If it turns out to be
useful enough that we should convert synaptics, then we should also
convert all the other drivers.  I agree that stuff like
@DRIVER_NAME at _la_LTLIBRARIES is a bit over the top, but sharing build
infrastructure between all the drivers is definitely a huge win, and I
don't see a compelling enough argument for synaptics to go out on its
own here.

Cheers,
Daniel