Am 24.03.2013 11:51, schrieb Helmut Auer:
Helmut Auer wrote:
Sorry to hack this thread , but my wound is still wide open :(
There also was a makefile concept for ten years and apparently no
one has a
problem with it, but it was changed and that that has cost me many
many hours
and days and all the fun I had with VDR before ...
Then please, finally, name your problems, so someone can help you to
find solutions.
There's nothing to find anymore, I had to debug crashes of a plugin
(not my own) which were caused by migrating to the new makefile,
because cflags and c++flags were differnet.
I can't imagine, that this is caused by a changed Makefile.
Which plugin are you refering to?
I searched for the segfault in the code but the reason was the make,
and that costs me some days.
And also the migration of many plugins costs me a lot of time.
You don't have to migrate them. You can stay with the old Makefiles.
Take a look at the VDR4Arch Project
https://github.com/CReimer/vdr4arch/blob/master/plugins/vdr-filebrowser/PKGBUILD
The old Makefile system did not work well for packaging and made it
unneccessarily difficult to build plugins from outside the VDR
source. It also
often required manual steps to be done after installing the plugin
(copy
resources or something like that) which can be done in the "install"
target,
now. So in my opinion the new system is a big benefit for 2.0.
Just for my point of view, I do not have any benefit of the new
makefile concept, only trouble.
This makefile change has lead to the biggest cut in VDR times, imho
such a change should be made after a major release not (in VDR times)
short before a major release.
If I'd be a a vdr user thats no problem, I can stay with vdr 1.7.32.
Bu unfortunately I'm a distributor and I've promised my users a new
version with VDR 2.0.
Now I have the choice between breaking my word or setting up the new
system which will cost me some more days with a system that I do not
like.
There's also a problem with your attitude. You want to provide all
plugins regardless of how old or how broken they are.
Christopher Reimer
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
