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 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.
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.
--
Helmut Auer, helmut@xxxxxxxxxxxxx
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
