Hi,
thank you Klaus for holding up your release plan for 2.0! However, I hope this minor patch won't be too much trouble for you, as it only increases the limit of 16 to theme and skin names, letting them be NAME_MAX as almost any files, since these names can also be involved in file names. Was there a good reason to limit them at 16 only, perhaps the fear that the name won't fit on the OSD? I don't really think someone would really make use of as many as 255 characters for this. On the other hand, users just encountered crashes with plugins which (unfortunately, yet) have themes of their own, when just adding a new theme with a name longer than 16 and at the same time the original plugin author relied on MaxThemeName when allocating the string length. So, what do you think, easy to adopt?
Regards, Lucian
On 23.03.2013 17:14, Lucian Muresan wrote:
Hi,
thank you Klaus for holding up your release plan for 2.0! However, I hope this minor patch won't be too much trouble for you, as it only increases the limit of 16 to theme and skin names, letting them be NAME_MAX as almost any files, since these names can also be involved in file names. Was there a good reason to limit them at 16 only, perhaps the fear that the name won't fit on the OSD? I don't really think someone would really make use of as many as 255 characters for this. On the other hand, users just encountered crashes with plugins which (unfortunately, yet) have themes of their own, when just adding a new theme with a name longer than 16 and at the same time the original plugin author relied on MaxThemeName when allocating the string length.
Those are bugs in the plugins and should be fixed there. Or is this something that can also happen in the core VDR?
So, what do you think, easy to adopt?
Well, for one, now is definitely not the right time for a change like this! And furthermore, skin and theme names should be short. What sense does it make to call a theme something like "This is the theme that implements a range of colors from 400 nanometers to 700 nanometers", when you could just plain simple call it "rainbow"? ;-)
So I'd say the limit is there for a reason, and should stay there.
Klaus
On 23.03.2013 22:50, Klaus Schmidinger wrote:
On 23.03.2013 17:14, Lucian Muresan wrote:
Hi,
thank you Klaus for holding up your release plan for 2.0! However, I hope this minor patch won't be too much trouble for you, as it only increases the limit of 16 to theme and skin names, letting them be NAME_MAX as almost any files, since these names can also be involved in file names. Was there a good reason to limit them at 16 only, perhaps the fear that the name won't fit on the OSD? I don't really think someone would really make use of as many as 255 characters for this. On the other hand, users just encountered crashes with plugins which (unfortunately, yet) have themes of their own, when just adding a new theme with a name longer than 16 and at the same time the original plugin author relied on MaxThemeName when allocating the string length.
Those are bugs in the plugins and should be fixed there. Or is this something that can also happen in the core VDR?
So be it, it's quite easy for plugins to ignore MaxThemeName or allocate such a string length, say 4*MaxThemeName as long as they mange their own themes... I did not test how VDR reacts when it is fed with a theme or a skin with a name longer than 16 (seems those are the only 2 places in VDR where you use those, on statically allocating the strings holding the theme and the skin, which you store to and load from setup...
So, what do you think, easy to adopt?
Well, for one, now is definitely not the right time for a change like this! And furthermore, skin and theme names should be short. What sense does it make to call a theme something like "This is the theme that implements a range of colors from 400 nanometers to 700 nanometers", when you could just plain simple call it "rainbow"? ;-)
Not necessary to exaggerate with such an hilarious example, you're getting near to sarcastic and missing the point, let's just take your short example in a more realistic scenario:
rainbow_1920x1080.theme rainbow_1280x768.theme
just because there still are plugins having to use skins which are resolution-dependent, so those names aren't at all that uncommonly long like your example, yet they try to carry some little useful information. And still, one of them is already violating the limit (if we do not consider the file extension). Of course, you might say, take out the '_', or the 'x', I could answer I'd rather take out some letter out of "rainbow", and so on, you see what I'm trying to point out, it's hitting a limit difficult to argue...
So I'd say the limit is there for a reason, and should stay there.
Could you at least please, name it?
Regards, Lucian
On 24.03.2013 10:49, Lucian Muresan wrote:
On 23.03.2013 22:50, Klaus Schmidinger wrote:
On 23.03.2013 17:14, Lucian Muresan wrote:
Hi,
thank you Klaus for holding up your release plan for 2.0! However, I hope this minor patch won't be too much trouble for you, as it only increases the limit of 16 to theme and skin names, letting them be NAME_MAX as almost any files, since these names can also be involved in file names. Was there a good reason to limit them at 16 only, perhaps the fear that the name won't fit on the OSD? I don't really think someone would really make use of as many as 255 characters for this. On the other hand, users just encountered crashes with plugins which (unfortunately, yet) have themes of their own, when just adding a new theme with a name longer than 16 and at the same time the original plugin author relied on MaxThemeName when allocating the string length.
Those are bugs in the plugins and should be fixed there. Or is this something that can also happen in the core VDR?
So be it, it's quite easy for plugins to ignore MaxThemeName or allocate such a string length, say 4*MaxThemeName as long as they mange their own themes... I did not test how VDR reacts when it is fed with a theme or a skin with a name longer than 16 (seems those are the only 2 places in VDR where you use those, on statically allocating the strings holding the theme and the skin, which you store to and load from setup...
So, what do you think, easy to adopt?
Well, for one, now is definitely not the right time for a change like this! And furthermore, skin and theme names should be short. What sense does it make to call a theme something like "This is the theme that implements a range of colors from 400 nanometers to 700 nanometers", when you could just plain simple call it "rainbow"? ;-)
Not necessary to exaggerate with such an hilarious example, you're getting near to sarcastic and missing the point, let's just take your short example in a more realistic scenario:
rainbow_1920x1080.theme rainbow_1280x768.theme
Themes are all about colors - why do they even need to mention resolutions?
Besides, skins should react dynamically on the current OSD size.
just because there still are plugins having to use skins which are resolution-dependent, so those names aren't at all that uncommonly long like your example, yet they try to carry some little useful information. And still, one of them is already violating the limit (if we do not consider the file extension). Of course, you might say, take out the '_', or the 'x', I could answer I'd rather take out some letter out of "rainbow", and so on, you see what I'm trying to point out, it's hitting a limit difficult to argue...
So I'd say the limit is there for a reason, and should stay there.
Could you at least please, name it?
Keeping the names *short* ;-)
This limit has been in there for almost ten years and has apparently never been a problem (at least not to my knowledge). I can't change that so close before the release of a major new version - even if it might look like it won't break anything. You can get back to me with this after version 2.0.0 is out. Version 2.1.x can pick up such changes again...
Klaus
Am 24.03.2013 11:00, schrieb Klaus Schmidinger:
This limit has been in there for almost ten years and has apparently never been a problem (at least not to my knowledge).
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 ...
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.
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.
Yours
Manuel
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.
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/PKGB...
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
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 ;)
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. 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/PKGB...
I already know this, but there were times without the compatibility flag.
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.
Thats your point of view I just want to build these plugins which are used by Gen2VDR users ...
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
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.
live still uses the old makefile and softhddevice works great here.
Christopher
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
On 24 March 2013 16:36, Lucian Muresan lucianm@users.sourceforge.net 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 for which plugins can base their Makefiles upon. Consider that most other apps that provide extension points for plugins to implements only provide pkg-config flags, and nothing else :)
Klaus is already doing people a massive favour by maintaining this Make system and continuing to support it. The changes in 2.0 were well agreed, refined and implemented. Any plugins that don't trivially build within the new way should be left up to their maintainer to fix, or interested parties to submit patches.
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 VDR, despite which Makefile system. This was IMHO a great job, to keep 99% of the old system with the view into the future.
With post 2.0 Klaus can now uncompromising cut everything old and unnecessary, which will probably sort out 80% of all plugins and make distributors live even easier ... ^^
Thanks for this great work up to now Klaus!
=== Kind regards fnu
On Sun, Mar 24, 2013 at 9:36 AM, Lucian Muresan lucianm@users.sourceforge.net 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? 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.
I've seen enough coder complaints to know it's an unwritten rule of thumb that when you patch things and it changes/breaks vanilla behavior, it's your responsibility to maintain and fix anything that gets lamed. Rather than expecting Klaus to cater to such cases, you should appreciate he's willing to consider them.
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 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.
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 DEFINES even after installation!
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.
The extension patch already patches *many* files in the VDR source, so as it requires the DEFINES to be exported, it should also patch the Makefile to export them in the cflags variable in vdr.pc.
Yours
Manuel
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 DEFINES even after installation!
Quite possible that it is broken by design, but if used carefully (i.E. giving all of these DEFINES to all of the plugins built against that specific patched VDR version, should give all of them the same API) it works.
The extension patch already patches *many* files in the VDR source, so as it requires the DEFINES to be exported, it should also patch the Makefile to export them in the cflags variable in vdr.pc.
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. 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 as it was.
So it takes two to tango, plugin Makefiles also have to use those DEFINES, it's not enough that they are provided in some place everyone has agreed upon. That was my point actually, while Klaus is doing a great job, some of the plugin authors failed to do so, which is also only human, I only would have given them less opportunity to fail...
Regards, Lucian
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 as it was.
I think the best way to get compatible with old vdr versions is to manually create a vdr.pc file. Then plugins with new Makefiles will just build. This should be up to the distributors. Just copy one from a recent vdr and edit the API version and paths... Have done it with the current stable-vdr 1.7.27 in yaVDR.
For plugins with old Makefiles: just get the needed variables from vdr.pc in your build-script (pkg-build, debian/rules etc.) and you're done.
I like the new Makefile... :)
I don't like defines in headers, it's just a source of error noone should be forced to manage. Wrapping multiple patches into each other can only be maintainable if you don't make them selectable. The distributor decides which patches he/she likes to distribute and maintaining a patch combination is awfull enough... Done that (and doing it) and I don't really like that either. :) But I will do it until there are no more patches *I* need... :)
Why argue about the new Makefile? It's done, get used to it...
Peace, Lars.
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 the "extension patch" requires plugins to get the DEFINES, then it should patch the VDR Makefile to forcefully add them to vdr.pc, so Plugin-Makefiles get them even if no "PLGCFG" is used.
Yours
Manuel
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 circumvented it by mistake.
*Wrong way* to fix this! If the "extension patch" requires plugins to get the DEFINES, then it should patch the VDR Makefile to forcefully add them to vdr.pc, so Plugin-Makefiles get them even if no "PLGCFG" is used.
The Gentoo Gentoo VDR maintainer eventually fixed it in _some_ way achieving this (don't think there is only *your* solution to the problem, by fixing the makefile), namely have the DEFINES listed in the flags in vdr.pc.
Your definition of *wrong way* holds only in the unfortunately now already established scenario that everyone is free to use the template plugin makefile generated by the newplugin script solely as an orientation, and omit anything which doesn't *seem* to break things in his own use case, and of course, the use case "make LCLBLD=1". So while the new makefile system as a whole (with vdr.pc and so) _is indeed better_ than the old one, it just still allows too many possibilities for the plugin developer to break things for others [1], or even to get himself into some trouble [2], or just be lazy and not provide complete install targets [3].
So I just want to fight this fake belief which some people (I do not mean Klaus by that, who did not make this up by himself, but responded to and consulted people) try to establish, that the new makefile system is near to perfect and covers everything. I'm also not with those people who denigrate it entirely, just wanted to say it has some flaws, it should be allowed to do so without being slapped by every second reply, and can only re-iterate that I'm sorry I did not have the time to tell my opinion earlier.
Best regards, looking forward for the 2.1 series... Lucian
[1] the already discussed DEFINES situation;
[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 about unresolved symbols;
[3] completely missing usage of RESDIR which also can be read out of vdr.pc and any sample commented out target using it, that way many plugin authors continue just to ignore it even if their plugin actually comes with lots of non-program files we all call resources, which have to be installed under a certain pattern, only modifiable by the RESDIR variable. Could continue with CACHEDIR, but that applies to less plugins... You will say this is up to packagers, but actually since there are these modifiable variables, and also some files have to comply to a certain directory pattern, this can be well prepared by the plugin author, it's only about his plugin, and the packagers just have to divert those variables specific to their distribution and the plugin would still work without further modifications, and not fight with doing missing targets for so many plugins...
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 about unresolved symbols;
+1
That should be included in the next developer cycle in the plugins' Makefile. Have stumbled upon this two or three times. I do know it now but the next one will hit it for sure. :)
[3] completely missing usage of RESDIR which also can be read out of vdr.pc and any sample commented out target using it, that way many plugin authors continue just to ignore it even if their plugin actually comes with lots of non-program files we all call resources, which have to be installed under a certain pattern, only modifiable by the RESDIR variable.
It would be nice, if the plugin's install target would install its resources to its well defined resource directory (it's $RESDIR/plugins/$PLUGIN, isn't it?). That would make packaging even more easy.
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 files. Or am I wrong?
You will say this is up to packagers, but actually since there are these modifiable variables, and also some files have to comply to a certain directory pattern, this can be well prepared by the plugin author, it's only about his plugin, and the packagers just have to divert those variables specific to their distribution and the plugin would still work without further modifications, and not fight with doing missing targets for so many plugins...
Lars.
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 files. Or am I wrong?
You are not wrong at all, but I actually mean less installing files into CACHEDIR but rather creating the subdirectory structure there, as it is expected by that plugin (sometimes it involves the plugin name, sometimes it's more generic, like for example several plugins sharing so-called epg-images which are fetched by some script and can be used for displaying by different plugins, so they would rather use a directory name not necessarily bound to some plugin name...). But then, again, I can agree it's arguable if that's not better a runtime option anyway...
Regards, Lucian
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 previously resolved.
All I hope is that when the dust settles from the Makefile madness, VDR hasn't been turned into a mess.
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 think it should be the target of any installation files. Or am I wrong?
You are not wrong at all, but I actually mean less installing files into CACHEDIR but rather creating the subdirectory structure there, as it is expected by that plugin (sometimes it involves the plugin name, sometimes it's more generic, like for example several plugins sharing so-called epg-images which are fetched by some script and can be used for displaying by different plugins, so they would rather use a directory name not necessarily bound to some plugin name...). But then, again, I can agree it's arguable if that's not better a runtime option anyway...
Since the cache directory is writeable by the vdr I think the plugin should create its files and folder at runtime.
Example: osdteletext, which caches several pages from TTX. It should create its folder $CACHE_DIR/plugins/osdteletext on startup and then create and delete files if needed.
Lars.
Regards, Lucian
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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 incompatibilities.
I can understand your frustration - changing a myriad of packages is an annoying task (been there - done that! :-)
But after all I think the new Makefile is much better and for the first time works out of the box with the standard Debian packaging tools (which require *FLAGS, DESTDIR, PREFIX and so on).
Packaging is much easier right now as you basically only have to do:
make all PREFIX=/ ... make install DESTDIR=...
And for plugins that haven't migrated to the new Makefile the only change I had to do was:
export CXXFLAGS += $(shell pkg-config vdr --variable=cxxflags)
The only thing I'm missing is a CPPFLAG in the Makefiles, which I hope gets added in 2.0+X.
But I'm talking from the Debian/Ubuntu perspective only - things might be slighty more complicated in Gentoo.
Tobias
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_OFFSET_BITS=64 there should be no ABI incompatibilities.
I can understand your frustration - changing a myriad of packages is an annoying task (been there - done that! :-)
But after all I think the new Makefile is much better and for the first time works out of the box with the standard Debian packaging tools (which require *FLAGS, DESTDIR, PREFIX and so on).
Packaging is much easier right now as you basically only have to do:
make all PREFIX=/ ... make install DESTDIR=...
And for plugins that haven't migrated to the new Makefile the only change I had to do was:
export CXXFLAGS += $(shell pkg-config vdr --variable=cxxflags)
The only thing I'm missing is a CPPFLAG in the Makefiles, which I hope gets added in 2.0+X.
But I'm talking from the Debian/Ubuntu perspective only - things might be slighty more complicated in Gentoo.
Well, see my other answer to Christopher, where I explained what can go wrong (which of course, doesn't have to happen if using plain vanilla VDR).
Regards, Lucian
On Sun, Mar 24, 2013 at 5:24 AM, Helmut Auer vdr@helmutauer.de 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 was getting crashed. Johns acknowledged the plugin had issues with the new Makefile and recommended to continue using the provided old-style Makefile. So are you saying that you've actually fixed softhddevice so it works correctly and no longer crashes when using the new-style Makefile? If so, would you mind submitting that patch to Johns so he can merge it?
Am 24.03.2013 15:48, schrieb VDR User:
On Sun, Mar 24, 2013 at 5:24 AM, Helmut Auer vdr@helmutauer.de 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 was getting crashed. Johns acknowledged the plugin had issues with the new Makefile and recommended to continue using the provided old-style Makefile. So are you saying that you've actually fixed softhddevice so it works correctly and no longer crashes when using the new-style Makefile? If so, would you mind submitting that patch to Johns so he can merge it?
I don't know whether Tobi started his plugin from scratch, or used our yavdr package as template, but we don't have crashes either. With vdr 1.7.41 and 1.7.42 and softhddevice 0.6.0 there are no Problems at least with vdpau on 64 bit systems. The only used patch (attached) has nothing to do with the new makefiles.
Gerald
!DSPAM:514f1e83250661305017642!
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 recommended to continue using the provided old-style Makefile. So are you saying that you've actually fixed softhddevice so it works correctly and no longer crashes when using the new-style Makefile? If so, would you mind submitting that patch to Johns so he can merge it?
Sorry to say - I haven't fixed that, after I recognized that this ***** makefile stuff was the reason I switched back to vdr.1.7.32 and stopped every development for newer versions.
Hi,
On 24.03.2013 11:00, Klaus Schmidinger wrote: [...]
rainbow_1920x1080.theme rainbow_1280x768.theme
Themes are all about colors - why do they even need to mention resolutions?
Besides, skins should react dynamically on the current OSD size.
as mentioned right after giving the example, that's the way some of the themes unfortunately work, but that's due to the technology they use (they are displaying background images and the like, which are pre-generated for that exact resolution, possibly a dynamic scaling won't look right in those cases). On the other hand, I'm completely with you, they should behave better, but they are not my skins, nor do I particularly use them, I was only trying to help the users a bit, which add such skins without touching any code...
just because there still are plugins having to use skins which are resolution-dependent, so those names aren't at all that uncommonly long like your example, yet they try to carry some little useful information. And still, one of them is already violating the limit (if we do not consider the file extension). Of course, you might say, take out the '_', or the 'x', I could answer I'd rather take out some letter out of "rainbow", and so on, you see what I'm trying to point out, it's hitting a limit difficult to argue...
So I'd say the limit is there for a reason, and should stay there.
Could you at least please, name it?
Keeping the names *short* ;-)
Seriously ;) ?
This limit has been in there for almost ten years and has apparently never been a problem (at least not to my knowledge). I can't change that so close before the release of a major new version - even if it might look like it won't break anything. You can get back to me with this after version 2.0.0 is out. Version 2.1.x can pick up such changes again...
That's fair enough and also ok with me, thanks.
Regards, Lucian
-
Christopher Reimer -
Dominic Evans -
fnu -
Gerald Dachs -
Helmut Auer -
Klaus Schmidinger -
Lars Hanisch -
Lucian Muresan -
Manuel Reimer -
Tobi -
VDR User