On 24.03.2013 14:10, Christopher Reimer wrote: > Am 24.03.2013 13:51, schrieb Lucian Muresan: >> Hi, >> >> On 24.03.2013 13:24, Helmut Auer wrote: >> [...] >>>>> 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. >>>> >>> There are lots of things that you can't imagine ;) >>> >>>> Which plugin are you refering to? >>>> >>> softhddevice and live Plugin. >>> There was a mismatch between c an c++ flags and this was surely >>> caused >>> by the new makefile system :) >>> >>> >>>>> I searched for the segfault in the code but the reason was the >>>>> make, >>>>> and that costs me some days. >> >> I could give you another example, Christopher, of which Makefile was >> migrated by yourself, with exactly the consequence pointed out by >> Helmut, I only don't think we're allowed to mention that plugin here, >> so >> just remember, 3 months ago, "Issue #18" of that Plugin on Github... >> >> Regards, Lucian >> > > Even before Issue 18 was fixed it worked flawlessly on Archlinux. Well, and therefore you concluded it ought to work on any system, but that's not necessarily true. I wonder, do you use vanilla VDR or a patched VDR on Archlinux? Gentoo uses the extended patch, it's just the way it is, users are just glad that this is possible for them, and when doing so it is absolutely necessary that all of the plugins are built with the exact same DEFINES introduced by the patches, and that happens to well, happen or not, in the plugin Makefile. Ignoring them, just because of thinking "plugin A does not use any of the patches X, Y or Z, so I don't need the DEFINES" is likely to give you a working plugin only if you are _very_ lucky, otherwise unexpected crashes will bite you. To take this out of the fortune domain one would have to either analyze with some true coverage techniques that absolutely no patched code is called in a specific plugin (and by that I mean, VDR internal code is also calling itself, so that's why an analysis is not trivial), or to just make sure, give the DEFINES to all of the plugins. So it turns out that the new Makefiles are just adopted in a different way by people, and also there was no clear directive where to store the DEFINES in case of patches, in /usr/include/vdr/Make.conf (or how it should be called lately), or right into the cxxflags and cxflags in vdr.pc... So you see, the whole process caused also a lot of confusion, also because each Makefile contains the whole logic, I would have placed the logic in a central, pseudo-Makefile shipped with the vdr sources, and generated some kind of Makefile stubs for the plugins, including the central one for the logic, and providing plugin-specifics (even custom, additional targets) through a well defined interface. That way, once the interface would have been established, the central logic could have been adapted fromtime to time without having to ever touch plugin Makefiles again. Unfortunatley, for me it just wasn't the right time to interfere in the makefile discussions when they were elaborated. I might come back with a drop-in proposal by the the time of the next developent series, quite possible that having only a few lines makefiles would be interesting for someone... Regards, Lucian _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
