Synaptics: a number of issues with commit 39afe69ad7d2

[Diego Elio Pettenò]

Il giorno mar, 14/06/2011 alle 19.16 +0100, Daniel Stone ha scritto:
> > 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.

Yes and no; one thing I have noticed here, especially when running (in a
sort-of-tight loop) a number of build processes in parallel, is that the
process spawning by make to get into subdirectories can be detrimental
as well. The main problem being that the process spawning itself tends
to sap away entropy to initialize canaries and the like, so when you
have a huge number of processes (say 400) spawned in a short time (2
seconds), every bit counts.

> 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 wouldn't mind helping out with converting the rest of drivers if you
wanted, certainly I would be happy for that to happen given that even if
small drops of improvement, it would total a nice improvement when
summed up.

Which is an unfortunate shared point: each project alone repeats that
changing their way is effort for no real gain. But on the whole, if they
all converted to the more efficient non-recursive approach, the gain
would probably be of a couple of hours.

For Gentoo I'm running a continuous integration build system, and
unfortunately it rarely gets to max out the parallel builds for more
than a burst of time, even if there is space to, simply because
recursive make is considered easier to write...

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

Right, do note that @DRIVER_NAME at _la_LTLIBRARIES has no real advantage
over input_LTLIBRARIES especially if you move inputdir definition within
xorg-macros themselves. 


-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/