On Mon, 14 Apr 2008 01:34:26 +0200 Diego Biurrun <diego@biurrun.de> wrote:
On Sat, Apr 12, 2008 at 03:31:36PM +0200, Alban Bedel wrote:
so the new flat build system is underway. Sadly IMHO it have a few shortcomings and there is some things that I think we should discuss here before going any further.
The most important point IMHO, is do we really get rid of the .a or not? On the plus side I only see a few rule less in the Makefile. On the minus side the whole source list is required for any tool using the lib in question.
We would just need the relevant object files. You do have a point that this can be a burden to maintain.
IMHO if we don't have the .a anymore we should have an includeable Makefile with the corresponding file list. Otherwise anybody wanting to use this code (that is us in the case of the tools) must duplicate a good part of our build system, and keep up with any change in it.
Note that every time I have merged a subdirectory makefile into the top-level one, there was a net reduction in linecount.
No doubt there, but line count alone is not everything. A few lines more is well worth it if it cut down on maintenance, or improve reusability.
Then there is the problem that now all sources are grouped together. It completely prevent any sane build system for the tools. Even if we drop the .a we need to keep a source list for each lib. Anything else is just too inflexible.
If we keep separate lists we might as well put them in $LIB/Makefile and support building from the lib's dir. The latter is easy to achieve with some include. And still having separate Makefiles would make things easier for newcomers than having to dive in a 5000 lines Makefile.
I don't buy the 50 small makefiles are simpler than a big one argument. If you look at the top-level makefile and disregard the cruft that is going to go away when recursive make is eliminated - then it is really quite simple. There are some long list of objects/sources in there, but long lists are not really more complicated than short lists.
I agree. However when you compare: SRCS = liba/foo.c \ liba/bar.c \ libb/b.c \ libb/c.c \ main.c \ which is useless for any tool needing only liba, to: SRCS_LIBA = liba/foo.c \ liba/bar.c \ SRCS_LIBB = libb/b.c \ libb/c.c \ SRCS = $(SRCS_LIBA) \ $(SRCS_LIBB) \ main.c \ It's not like the second form make things much more verbose or complex. And such form would also limit the need for "double condition" variables.
For FFmpeg it makes sense since some directories are used independent of the whole thing, but for MPlayer I think not.
I dunno. There is many useful code in MPlayer, in particular stream, libao and libvo have no equivalent with such wide support AFAIK. If using them outside of MPlayer was simpler I'm pretty sure they would see some more use (== more bug fix/improvements for us). Albeu