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

Gaetan Nadon memsize at videotron.ca
Wed Jun 15 14:24:02 PDT 2011


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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110615/9dd90a2c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110615/9dd90a2c/attachment-0001.pgp>


More information about the xorg-devel mailing list