Am 28.03.2013 00:20, schrieb Lucian Muresan:
> On 27.03.2013 23:07, Lars Hanisch wrote:
>>> Could continue with CACHEDIR, but that applies to less
plugins...
>> I understand CACHEDIR as a location for runtime generated data which
>> doesn't necessarily survive reboots of the vdr. I
>> don't
I'm just curious.. Is there any other software anyone can think of
that had so much controversy surrounding a Makefile? I'm not aware of
any myself but that doesn't mean much. Surely there's enough packaged
software out there that methods for these problems, if that's what
they are, have been prev
On 27.03.2013 23:07, Lars Hanisch wrote:
>> Could continue with CACHEDIR, but that applies to less
>> > plugins...
> I understand CACHEDIR as a location for runtime generated data which doesn't
> necessarily survive reboots of the vdr. I
> don't think it should be the target of any installation f
Hi,
Am 27.03.2013 18:40, schrieb Lucian Muresan:
> [2] for example, an empty LIBS variable, also used in the correct order
> (after OBJS) in the final link statement, just for the case that a
> plugin have use them, it could have spared some authors of putting it in
> wrong order and then wonder a
On 26.03.2013 17:19, Manuel Reimer wrote:
> Lucian Muresan wrote:
>> So it does on Gentoo, but the problem was with various plugin makefiles
>> actually, which claimed to be "new style" but for whatever reason the
>> persons who adapted them to the new style removed including $(PLGCFG) or
>> circum
Lucian Muresan wrote:
So it does on Gentoo, but the problem was with various plugin makefiles
actually, which claimed to be "new style" but for whatever reason the
persons who adapted them to the new style removed including $(PLGCFG) or
circumvented it by mistake.
*Wrong way* to fix this! If th
Hi,
Am 25.03.2013 20:09, schrieb Lucian Muresan:
> That is also due to some acrobatic
> conditional constructs in some desperate tries to keep the same
> makefiles also backwards compatible with a whole lot of older VDR
> series, instead of just providing the old makefile under another name
> just
On 25.03.2013 17:36, Manuel Reimer wrote:
> The best way to resolve this would be to switch to separate patches as
> soon as possible. The extension patch is broken by design, as it causes
> the VDR to place header files with conditional compiling expressions. So
> the API changes based on the DEFI
Lucian Muresan wrote:
I wonder, do you use vanilla VDR or a patched VDR on Archlinux?
https://github.com/CReimer/vdr4arch/blob/master/vdr/PKGBUILD#L31
One patch (MainMenuHooks) which doesn't change anything on the plugin API.
Gentoo
uses the extended patch, it's just the way it is, users are
softhddevice and live Plugin.
There was a mismatch between c an c++ flags and this was surely caused by
the new makefile system :)
When using the new style Makefile supplied with softhddevice git, I
was getting crashed. Johns acknowledged the plugin had issues with the
new Makefile and recomme
On Sun, Mar 24, 2013 at 9:36 AM, Lucian Muresan
wrote:
>> 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? Gen
> Klaus is already doing people a massive favour by maintaining this Make
> system and continuing to support it.
FullAck, I guess most people appreciate this way, it makes live not that
bad, some minor changes needed to keep any plugin. There's more work for
many plugins regarding other changes in
On 24 March 2013 16:36, Lucian Muresan wrote:
>> 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.
>
> *SNIP*
>
tbh VDR is quite unusual that it provides this 'template' system
On 24.03.2013 14:15, Tobi wrote:
> On 24.03.2013 13:51, Lucian Muresan wrote:
>
> I searched for the segfault in the code but the reason was the make,
> and that costs me some days.
>
> There's not very much which go wrong. As long as the plugins are
> compiled with -fPIC and -D_FILE_OFFS
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
Am 24.03.2013 15:48, schrieb VDR User:
On Sun, Mar 24, 2013 at 5:24 AM, Helmut Auer wrote:
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 :)
When using the new style Makefile su
On Sun, Mar 24, 2013 at 5:24 AM, Helmut Auer wrote:
>> 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 :)
When using the new style Makefile supplied with softhddevice git, I
On 24.03.2013 13:51, Lucian Muresan wrote:
I searched for the segfault in the code but the reason was the make,
and that costs me some days.
There's not very much which go wrong. As long as the plugins are compiled
with -fPIC and -D_FILE_OFFSET_BITS=64 there should be no ABI
incompatibilitie
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
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 Mak
Hi
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 ;)
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 t
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 ple
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 ple
24 matches
Mail list logo
