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:
make
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"
Yours
Manuel
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
