[PATCH input-synaptics 1/2] Revert "build: collapse all Makefile.am files into a single non-recursive one."

[Peter Hutterer]

On Wed, Jun 15, 2011 at 05:24:02PM -0400, Gaetan Nadon wrote:
> On Wed, 2011-06-15 at 17:14 -0400, Gaetan Nadon wrote:
> 
> > This reverts commit 39afe69ad7d2258d4043044d1283bd6e311e48da.
> > 
> > Conflicts:
> > 
> >         .gitignore
> >         Makefile.am
> > 
> > This patch is to review "non-recursive make" commit 39afe69ad7.
> > Nak this patch to signify your approval of commit 39afe69ad7
> > Ack this patch to revert "non-recursive make" commit 39afe69ad7
> > This will formalize the review being held on xorg-devel list.
> > 
> > http://lists.x.org/archives/xorg-devel/2011-June/023321.html
> > http://lists.x.org/archives/xorg-devel/2011-June/023233.html
> > 
> > There are a couple of minor code changes unrelated to makefile
> > recursiveness
> > which can be resubmitted should the revert be accepted:
> > @DRIVER_NAME at _drv_ladir = @inputdir@ to
> >   input_LTLIBRARIES = @DRIVER_NAME at _drv.la
> > noinst_PROGRAMS to check_PROGRAMS
> > 
> > 
> 
> My review comments, taking into consideration what has been written so
> far.
> 
> Everyone is in favor on speeding up builds. A quick test indicates there
> is no performance benefit. Are there any prototypes to support the
> claim? What can I do to verify that building is faster on an average
> computer?
> 
> If the benefits only show up when multiple modules are non-recursive, it
> should be able to demonstrate this with multiple copies of synaptics.
> 
> My readings indicate non-recursive makefile are faster for a large body
> of C code that spawns multiple subdirs which have a dependency
> relationship amongst themselves. As well, reviewers have indicated that
> simply invoking make in subdirs has very little performance impact.
> 
> The cost of collapsing all makefiles into one is not negligible and so
> is the on-going maintenance for the next decade or two. The benefits
> must be compelling to offset that cost. I could elaborate on this if
> need be.
> 
> On some larger modules, it may be a benefit to have a single makefile
> for the C code while retaining subdirs for docs, config, tools and what
> not. A compromise on the number of subdirs and other related work may
> yield significant performance gain. We just had a preview on the server
> with a convenience library.
> 
> I did see an attempt from Automake in 2001 to collapse makefiles on
> behalf on the user using an "import" statement. That has never
> materialized.

I'm in favour of reverting for now though I admit just because the new
Makefile.am is larger and more confusing than the previous approach. I have
not done any other benefit analysis.

One argument Diego had in his blog post was that documentation targets can
be slow. It might be worth trying this approach on one of the modules that
make use of asciidoc and docbook conversions. That way the results may be
more visible.

Cheers,
  Peter