On Mon, Jun 02, 2008 at 08:06:26PM +0200, Diego Biurrun wrote:
On Mon, Jun 02, 2008 at 07:07:22PM +0200, Nico Sabbi wrote:
sorry, but I really don't understand the reason for a single and totally flat Makefile: IMO a Makefile per directory is a kind of modularization (that is generally considered "A good thing" ) , clean for its own nature. Can you explain what we gain now? or in what respect a single Makefile is cleaner?
The single Makefile is shorter than the single-directory Makefiles combined, even with common infrastructure factorized into mpcommon.mak. Our Makefile is just above 1000 lines. Given that it consists largely of long lists, it is neither complicated nor particularly long. In such a case I prefer having all the information in one central place.
But this is not the main reason. The problem is that recursive Make is incorrect. What the Make program does is build a directed acyclic graph of all dependencies/targets and then perform all the necessary steps the target you request requires, but no more than those necessary steps.
Recursive uses of make cut this graph into pieces. Unfortunately this process is not lossless because inter-directory dependencies are left out. This results in Make systems that continuously recompile things unnecessarily, fail to recompile necessary parts and generally have horrible performance.
Note that it is possible to split Makefiles into pieces without the build process becoming recursive. You can use the 'include' Makefile directive to incorporate Makefile snippets from subdirectories into the top-level Makefile. It is even possible to build non-recursive build systems with Make where you can invoke Make from subdirectories, like Mans did for FFmpeg. But this does require a considerable amount of Make trickery. For MPlayer I did not see much added benefit to make up for the complication. In FFmpeg it makes sense to build single libraries separately. In MPlayer, you are interested in the binaries, which are built from the top-level. Diego