[MPlayer-dev-eng] The new Makefiles

[Diego Biurrun]

On Mon, Apr 14, 2008 at 03:08:49AM +0200, Alban Bedel wrote:
> 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.
 
I see no difference between

SRCS = foo.c bar.c baz.c

and

SRCS += subdir/foo.c subdir/bar.c subdir/baz.c

> > > 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.

This is completely orthogonal to the question of using one big Makefile
or splitting it up into multiple pieces.  Just define a variable and
then use it.  A subdirectory Makefile basically does just that.

> > 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).

I don't see a separate Makefile as any sort of simplification for this.
Note that the individual Makefiles depend on top-level Makefile snippets
as well as configure anyway.

Diego