[MPlayer-dev-eng] The new Makefiles

[Alban Bedel]

On Fri, 18 Apr 2008 09:54:05 +0200
Diego Biurrun <diego at biurrun.de> wrote:

> 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

But if a tool need only subdir/* it must recreate that second list. With
all the conditional used nowadays in the Makefiles that's far from as
trivial as it look here. And what for? To spare _one_ line in the main
Makefile.

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

I know this is orthogonal to splitting or not. And I don't care much if
it's split or not (although my preference is clear I think). All I want
is not to have to duplicate half the (non-trivial to create) file lists
when a tool use some of the lib.

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

Again I don't care much if the Makefiles are split or not. What I want
is not to increase the work in maintaining the tools.

Before the tools would break only when an _external_ dependency was
added to one of the lib (which ideally nearly never happen). Now they
will also break anytime a file is added or removed from a lib (which
happen way more often). Now, how you can argue that the latter is better
is just beyond me.

I would suggest you try to merge the tools Makefile next. If you take
the approach you suggest you will clearly see that the 3 lines you so
bitterly want to spare become a couple dozen more and a clear burden on
maintenance.

	Albeu