[MPlayer-cvslog] r22798 - trunk/libdha/Makefile

[Benjamin Zores]

Rich Felker a écrit :
> On Sun, Mar 25, 2007 at 07:22:02PM +0200, Diego Biurrun wrote:
>> On Sun, Mar 25, 2007 at 07:18:07PM +0200, Benjamin Zores wrote:
>>> Diego Biurrun a écrit :
>>>> On Sun, Mar 25, 2007 at 01:10:31AM -0500, Rich Felker wrote:
>>>>> On Sat, Mar 24, 2007 at 03:20:24PM +0100, diego wrote:
>>>>>> Log:
>>>>>> Build shared lib on all platforms.
>>>>> This should be tested at configure time. There's not necessarily any
>>>>> way to build a shared lib. (In particular my system does not support
>>>>> shared libs.)
>>>> I've always wondered why libdha and VIDIX were built as shared libs at
>>>> all.  It's not like they're really used outside of MPlayer AFAIK.
>>> I wanted to make them static as most as possible and have all drivers 
>>> built-in but:
>>> - this implies potential API rewrite.
>> Why?  Can't we just link statically and be done with it?  At least the
>> MPlayer copy?
> 
> Agree. Or better yet, make a kernel wrapper for the vidix drivers that
> exposes an api identical to mga_vid kernel module, and then just use
> -vo mga to access them without needing root access. It shouldn't be
> hard.
> 
>>> - Nick is against the idea cause the current way allows having 
>>> closed-source vidix drivers as external .so (judging by the API's 
>>> stability and whole project's status, no one will ever such such though).
>> Forget it, no proprietary shop is going to bother with something as
>> obscure as VIDIX.
> 
> Indeed, Nick is an idiot and this is contrary to our goals of free
> software. I'm all for fixing the api to allow static linking, and
> making MPlayer always link vidix static.

The more i think about it, the more i'm wondering why i've ported back 
changes from MPlayer to vidix.sf.net.
As for now, external vidix doesn't work at all with MPlayer, only 
built-in does.

Besides, whatever I could have told to Nick, he's totally opposed to any 
changes towards current vidix project (except from driver addition of 
course).

Also, even if external libdha/vidix work again against MPlayer some day, 
it really fear about all the Makefile stuff, between what have changed 
in MPlayer SVN and what doesn't in vidix.sf.net repository.

Maybe the best solution ever would be to definitely fork vidix.sf.net.
Start from our internal libdha/vidix (maybe in a dedicated repo but 
whatever) that is known to work, change the API and build scripts to 
what we really need, then port the drivers enhancements from 
vidix.sf.net that really worth it (and it will be easier to test changes 
this way). I can still watch vidix.sf.net commits to see if suddenly 
something gets commited if it worth getting merged to our repo.

It'll probably be the only way to have updated vidix though.

Ben