-
Gaetan Nadon authored
This reverts commit 39afe69a . 1. For such a small module, the build time improvement is most likely negligible. At least, I'd like to see some timings proving it's worthiness before seeing the patch go back in. 2. This kind of change would need a thorough review. The need to operate the build from a single toplevel Makefile is a significant change. The two most noticeable issues for me are that collapsing all the Makefiles could easily cause namespacing issues with the variables, and operating on files outside the current directory can introduce subtle bugs. I feel that the non-recursive style is generally less robust than the standard recursive make scheme. 3. It's unlike all the other X.org modules. This isn't a showstopper for me, but the recursive style is well understood here and you've beaten all the modules into a consistent format that makes build bugs unique to specific modules less likely. Acked-by: Dan Nicholson <dbn.lists@gmail.com> To give a concrete example for #3 above, the 175 man pages are much easier maintained using a very similar makefile in the man directory of all X.Org module. The cost of maintaining a single makefile is much higher. Every target in the makefile has to be reviewed and tested when changes are made. Not everyone has the all the skills to handle widely different targets such as man pages, DocBook/XML, librairies, C code, distribution hooks, and so on. Acked-by: Daniel Stone <daniel@fooishbar.org> Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
cb6818b6