[MPlayer-dev-eng] The new Makefiles

[Alban Bedel]

On Mon, 14 Apr 2008 01:34:26 +0200
Diego Biurrun <diego at 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