[MPlayer-cvslog] r26914 - in trunk: DOCS/xml/en/video.xml Makefile drivers/Makefile

The Wanderer inverseparadox at comcast.net
Wed Sep 10 23:23:48 CEST 2008


Diego Biurrun wrote:

> On Wed, Sep 10, 2008 at 12:33:00PM -0400, Rich Felker wrote:
> 
>> On Wed, Sep 10, 2008 at 06:17:03PM +0200, Diego Biurrun wrote:

>>> And the build system will keep using a monolithic Makefile as
>>> long as I keep maintaining it, that decision is final.
>> 
>> I have a mixed opinion on this. I've of course always supported the
>> monolithic makefile, but drivers/ is not part of the MPlayer
>> build. It's separate linux-specific drivers that just happen to be
>> included in the MPlayer repo for convenience and historical
>> reasons.
> 
> They are not the only Linux-specific things, there is more below
> vidix/.
> 
>> There's no reason one would build these as part of building
>> MPlayer, or vice versa.
> 
> That's completely orthogonal to the question of having the rules that
> are used to build them in the same file.

I'm not sure that is the case. I'm also not sure that the
"Linux-specific" point is really central.

I think the relevant question is: would it be possible to just take the
drivers/ subdirectory, delete the rest of the MPlayer source tree, and
build (and later install and potentially use) the drivers using only the
files left in that directory? Are the drivers, in other words, not
actually part of MPlayer at all?

If so, then that directory is effectively just as standalone as any of
the externals, and it should (imperative "should") be possible to so
pull out the directory without having to lose the build logic in the
process.

If not, then there is no particular benefit to having the build logic
separate, and it should be treated just like any other subdirectory.

-- 
       The Wanderer does, for the record, support the monolithic 
Makefile in general terms

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.



More information about the MPlayer-cvslog mailing list