Klaus Schmidinger wrote:
Never in my wildest dreams would I have expected such an outrage about this
change, which was entirely intended to make things simpler in the future.
But if this is not what people want, then let's just stick with the old
Makefiles and declare version 1.7.34 a complete and utter failure...

The changes in 1.7.34 are a big change into the right direction!

In context of a plugin, VDR should be something like a "backend library". It has to be installed, but the plugin should be compilable from *everywhere* as long as the "backend library" is there.

This is why pkg-config was invented and this is how all other software projects out there work.

VDR, so far, had a *very* special Makefile system. Running "make", even if VDR is installed, just failed and the lack of "make install" causes the need that plugin authors have to document how to *manually* complete the installation as the Makefile won't do it and can't do it.

So nearly every plugin needs its own way to compile it from outside of a VDR source (that most distributions don't even install, as they only install the "include-directory") and even more plugins need special handling to get it equipped with all those additional files, they need to operate (images, stillpictures, ...).

With the new system, anything should work with two commands:


followed by

make DESTDIR=... install

Of course there is now some additional work to get *useful* usecases of the old Makefile system to work again. Klaus already started with a first patch and I'm sure we can resolve other issues, too.

And about all those "unsupported" plugins: Do we really want to freeze all VDR interfaces just to keep those old, unsupported things working? If the original author lost interest, then there are only two options: Someone has to take it over or it should be dropped at all.

Beware - I'm not kidding about this! If this whining keeps going on, I will
switch back to version 1.7.33 Makefiles, and I won't dare touch them again
any time soon! After all, I didn't make this change because *I* wanted it...

And with the next changes in the "editing code", "EPG code" and "$WHATEVER code" the next one whines and you offer to "freeze" that part of code, again?

So why not freeze VDR development at all?

Or maybe, the people, that so much like the current status of VDR 1.7.33 (or maybe 1.7.31?) just roll their own fork and do whatever with it, so innovation in the core VDR project can go on?

Just remember: "Nobody likes change except a wet baby"



vdr mailing list

Reply via email to