[XviD-devel] xvid 1.0 question

[Edouard Gomez]

elcabesa (elcabesa at inwind.it) wrote:
> how fast is xvid moving to version 1.0?
> and after 1.0 release you think it's time to post mplayer patch for version 
> 1.. or it's better wait??

both versions could coexist, we only  need to make sure mplayer links to
the major version of the lib.

I changed a bit the way XviD is named on GNU/Linux so now we have:

XviD 0.9.x: libxvidcore.so.2.1 old SONAME=libxvidcore.so new for upcoming 0.9.2 SONAME=libxvidcore.so.2
XviD  HEAD: libxvidcore.so.3.0 SONAME=libxvidcore.so.3
XviD 1.0  : libxvidcore.so.4.0 SONAME=libxvidcore.so.4

For MacOSX and dylib target, i respect the same rule but i apply apple
recommendations:

XviD 0.9.x: libxvidcore.2.dylib compatibility_version=2 current_version=x
XviD HEAD : libxvidcore.3.dylib compatibility_version=3 current_version=0
XviD 1.0  : libxvidcore.4.dylib compatibility_version=4 current_version=0

For the MacOSX and module target,  the rule is still not decided, if you
have any suggestion  (you, macosx users) then tell me  because i have no
idea how they are named. ATM, it's just libxvidcore.so iirc.

For BeOS, it's just libxvidcore.so.

<offtopic>
Sorry pete but i can't respect the XVID_VERSION, as we already used the
old  APIs  numbers  on  Unix  since  0.9.0, i  can't  choose  a  smaller
major.minor for API compatibility SO naming.
</offtopic>

So to answer  your question, elcabesa, you can  provide XviD 1.0 support
as long as  old support is still available for the  first weeks 1.0 will
be out.  Now, i know  that mencoder internals are probably preventing us
from providing both  support at the same time (in  the same binary).  It
would be decided at compile time with a configure option/detection.

-- 
Edouard Gomez-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030515/d977410f/attachment.bin