[MPlayer-dev-eng] awk...

[Nick Kurshev]

Hello, Arpi!

On Sat, 12 Jan 2002 23:07:18 +0200 (CEST) you wrote:

> Hi,
> 
> Hey, guys. Today mailing here was terrible...
> 
> Let me tell what do i think.
> Nick wants to develop some new driver api and port his drivers.
> He uses gawk for this work. He can't/doesn't want test with other
> versions of awk. I feel the same as with gcc 2.9six.
> We don't want to support that version. We know our code works with
> 2.95 and with 3.x (is there still any 3.x specific problems ?)
> (note: wvm8 thing was actually our (actually Kabi's) bug)
> 
> I agree with Nick, he tested with gawk, so supports only it.
> If somebody have mawk/xawk/yawk/etc then he should test it and
> report if it works or send patch to make it work.
> 
> You shouldn't send 50+ mails of flame, just a mail: hey, it works with mawk
> here. Add support to mawk too.
> 
> We're fortunatelly over this awk shitty, but it will occurs in the future
> again with other stuff. MPlayer has more and more dependencies.
> 
> Btw, I also agree with Gabucino in that drivers/ dir should be moved out
> from mplayer cvs one level. Or two.
> 
I've amazed - mplayer has so much 3rd projects (like loader and so on)
which are within of CVS tree and are duplicate of other CVS trees.
In the same time - VIDIX is native mplayer's technology and you want
to move it out? What about /main/drivers folder?
Btw: X11 has every driver within its CVS and it's ok.

> We should create cvs modules named mga-driver ati-driver or just mga and
> ati. And move driver stuff there. Ati users can checkout main and
> ati-driver, matro xuserscan checkout main and mga-driver and others can
> checkout only main and maybe skins.
How many drivers will be implemented for this technogy?
I guess - max 10-15 during 5 years.
These drivers are binded to mplayer's directories like /usr/lib/MPLAYER/vidix
executing "make install" perform installation of them and every new change within
sources will overwrite previously installed drivers and it's good.
If we'll move them out then users may forget checkout drivers when they will
have new interface or implemented features. It will only perform mess.
> 
> Btw, Nick: you shouldn't commit binary files to CVS.
> And commiting the pciids gzipped is a very very bad idea.
> - cvs uses gzip to transfer patches from server to clients.
>   so compressing won't save any bits of doenload for users
> - cvs log doesn't work for binary files, changes are untrackable.
>   i think only few lines of pciids changes so you'd better commiting
>   the text version. and update it frequently.
>   or just let users to get it from SF or their /usr/share/pci/
>   (detected by ./configure)
> 
Other CVS servers for such files send only message like:
--- NEW BINARY FILE ----
------------------------
What about mapdev.vxd? I have no source for this driver.
But I hope that Felix will be able to port mplayer on windows with using
vidix technology too.

> I was always against copying other CVS trees to our. It only causes desync
> and redundant data on user's machine.
> 
pci.db is not CVS like loader and other things.
But I can't require from users - be online when you compile mplayer to have access
to sf.net server.
> Btw, do you plan to work on liba52 3dnow stuff, or not?
AFAIK, Michael have imported or optimized stuff from libac3 to liba52 - or I'm wrong?
> In later case, i'll merge changes back to liba52 and remove it from our cvs.
> (letting users to get it from liba52 cvs, just like libavcodec)
> 
Coudl you explain me please this situation in detail?
> 
> A'rpi / Astral & ESP-team
> 
> --
> mailto:arpi at thot.banki.hu
> http://esp-team.scene.hu
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
> 


Best regards! Nick