[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xine-devel
Subject:    Re: [xine-devel] Re: [xine-cvs] CVS: xine-lib configure.ac,1.186,1.187
From:       Michael Roitzsch <mroi () users ! sourceforge ! net>
Date:       2003-11-02 15:48:10
[Download RAW message or body]

Hi Rocky,

> Some people like myself really don't want multiple copies of the same
> thing everywhere. For example, I know many projects include GNU
> gettext if it is not installed. However if an acceptable version of
> GNU gettext is around and one which is known to work with the
> project, as a user I prefer the installed version be used over some
> project's unshared copy of that. This is a *user* concern, not a
> gettext developer concern. The libcdio and vcdimager libraries use
> pkg-config and version numbers and those can be checked to ensure
> there is a working version in the same way that say a plugin checks
> an API number to make sure it is acceptable.
>
> Some xine developers seem unhappy with this because they believe a
> change to the libcdio or libvcdinfo library is going to break
> xine-lib. This is only a concern if the version check is for say
> libcdio >= 0.64 as it currently is and think it should be rather than
> libcdio == 0.64.

Well, as long as things work nicely, I would be fine with defaulting to 
the external versions. But for that, someone with knowledge of both the 
libraries and the xine part should oversee the versions required in 
xine-lib's configure.

> Now let's look at the flip side. We saw that recently that xine-lib's
> ffmpeg got very much out of sync

ffmpeg does not really count. Look at the patch in src/libffmpeg, our 
copy requires quite some changes to blend nicely into xine. Using an 
external version is not a good option.

> For myself, if there is a bug fix to libcdio or libvcdinfo, I'm not
> going to do the double work to change xine-lib (or any other project
> that insists on having a copy of the library). One of the many vocal
> and insistent people who feel this "has" to be in xine-lib should do
> that.
>
> Someone, (not me) added this line now to the CREDITS file in the
> top-level xine-lib directory:
>
> [project          version	     mediator
> libcdio	          0.64-cvs
>
> There is supposed to be a name at the end. That is currently
> missing.

Yes, your name is currently missing here.  ;)

Well, as noted above, that mediator should be someone who knows the libs 
and the xine plugin well enough. I can only think of you here, if you 
really want to see a name there.

Without a name there, it just means that anyone who feels that current 
versions are too old should go on and update the libs after testing the 
new ones.

> This suggests to me again that a user is better off the
> external library rather than the internal one.

I hope we are not dragged into the same old dicussion again...

> Which leads into the weirdness in the option --with-external-vcdnav
> (or --with-internal-vcdnav). VCDNAV is really inappropriate here. As
> was noted, there are two libraries: libcdio and libvcdinfo. (Well
> actually 3 since there's also libvcd). NEITHER OF THESE HANDLES
> NAVIGATION. The navigation part is inside xine lib or the old
> xine-vcdx.

./configure --help should clarify, but feel free to change that.

> Aside from the screwy and incorrect name, the one switch controls
> using both libraries. Since it's possible to have libcdio installed
> with out libvcdinfo (and libvcd) and since I think it better for the
> official libcdio to be used even if vcdimager-cdio isn't, this option
> needs to be turned into two. Probably
> --with-internal/external-libcdio and
> --with-internal/external-libvcdinfo.

Again, feel free to change things here, but make sure, it works for 
those who don't have the libraries. Last time it did not...

> This has been on my list of things to address and I'll look over
> Michael's patch in doing so.

My patch is simply the fix which I believe to be most secure, but you 
might not like it (since it defaults to the internal libs).
If you want to propose something else, we would need it better sooner, 
than later, because the current check in configure seems rather broken 
to me, because the --with-external-vcdnav has no effect.

But if we are going to use the external libs by default, you will have 
to find someone (maybe yourself), who oversees the versioning. 
Otherwise I strongly suggest to use the internal ones by default.

Michael

-- 
panic("Aarggh: attempting to free lock with active wait queue - shoot
 Andy");
	2.0.38 /usr/src/linux/fs/locks.c



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
xine-devel mailing list
xine-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xine-devel
[prev in list] [next in list] [prev in thread] [next in thread]