[vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35

Klaus Schmidinger Klaus.Schmidinger at tvdr.de
Fri Dec 28 14:37:11 CET 2012

On 28.12.2012 14:19, Udo Richter wrote:
> Am 28.12.2012 09:28, schrieb Klaus Schmidinger:
>> Well, if a plugin is no longer actively maintained, it's probably
>> time to drop it. You know what they say about dead horses ;-).
> Being actively developed and being needed are two different things. I wouldn't want to drop all the plugins that aren't under active development any more, as this would probably be true for 2/3 of my plugins.
>> If you put all your plugins into PLUGINS/src under the VDR source
>> directory (with
>> the old Make.global still in place), change into PLUGINS/src and do
>>    for i in *; do make -C $i all; done
>> I would guess that they build regardless whether they use an old or new
>> Makefile. Maybe you should give it a try.
> Nope, as you forgot to filter out folders with version numbers.

Well, it's a makeshift solution, so you could just make sure there are
only folders you want to be handled.

> Plus, any updated plugin (at least any built-in plugin) does no longer create the *.so.$APIVERSION file, and there's no generic way to do this.

Well, then maybe this works (haven't tested it):

   for i in *; do make -C $i all; cp $i/libvdr-$i.so ../../PLUGINS/lib/libvdr-$i.so.1.7.34; done

> All updated plugins require an additional make install, that will create the *.so.$APIVERSION in some folder defined in vdr.pc. However, some old-style plugins will do totally different things on make install, like xineliboutput for example.
> Thats why I wasn't even able to set up a running test build of my VDR yet, even though it complied without any issues: Total mess of .so files.

The question is whether you really *want* to get things running ;-)
It's totally up to you what you do.


More information about the vdr mailing list