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

Reply via email to