[vlc-devel] "approved" method for locating plugins dir
briggs at parc.com
Tue May 24 00:24:41 CEST 2011
On May 23, 2011, at 1:29 PM, Rémi Denis-Courmont wrote:
> Le lundi 23 mai 2011 23:12:43 Nick Briggs, vous avez écrit :
>> Is there an approved method for locating where plugins should be installed
>> from a standalone compilation/installation of a VLC module?
> Hmm no, I'm afraid I did not think about that.
>> I'm trying to maintain an access module (for CCNx, http://www.ccnx.org)
>> that is compatible with most versions of VLC,
> Binary compatibility is explicitly broken at every x.y.0 release. I guess
> you're using quite a pile of ifdefs. Then again, some plugin classes are more
> stable than others.
Fortunately, I only have to worry about source compatibility :-)
It's an "access" module, and so far, since 0.9.8 I've had to deal with:
- access seek method changed from int64_t to uint64_t
- info.b_prebuffered went away
- p_access->psz_path => p_access->p_location
- vlc_thread_create lost its last parameter (<= 0.9.9) but was then deprecated, and now un-exported (with other vlc_thread_xxx fns)
- access control ACCESS_GET_MTU went away
- vlc_savecancel/vlc_restorecancel introduced
- block_FifoPace was introduced but not exported prior to 1.1.0
which isn't too bad in the scheme of things.
>> but about March 2010 plugins
>> moved from $(vlclibdir)/modules to $(vlclibdir)/plugins, and there doesn't
>> seem to be a pkg-config value that reflects this.
> I can add a pkg variable, but as far as backward compatibility is concerned,
> you're going to have to hardcode $(libdir)/vlc/module for VLC < 1.1 and
> $(libdir)/vlc/plugins for VLC >= 1.1.0.
A okg variable would be perfect -- thanks! I currently have a hardcoded version check to drive the location but was concerned that I'd missed something.
> Rémi Denis-Courmont
-- Nick Briggs
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4649 bytes
Desc: not available
More information about the vlc-devel