Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
2012/12/25 Klaus Schmidinger klaus.schmidin...@tvdr.de: 3.) the file should be included into plugin Makefiles after having set PLUGIN and VERSION to be able to have some plugin-/version-dependent configuration. Agreed. No. Not agreed. Just use DEFINES+= in Make.config, and if that doesn't work, plugin makefiles have to be patched. There's also the possibility to add a Make.config to every plugin. Some plugin maintainer already started to include their own Make.config (e.g. http://projects.vdr-developer.org/git/vdr-plugin-ripit.git/tree/Make.config.template) Christopher ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
Hi, Am 26.12.2012 09:53, schrieb Christopher Reimer: 2012/12/25 Klaus Schmidinger klaus.schmidin...@tvdr.de: 3.) the file should be included into plugin Makefiles after having set PLUGIN and VERSION to be able to have some plugin-/version-dependent configuration. Agreed. No. Not agreed. Just use DEFINES+= in Make.config, and if that doesn't work, plugin makefiles have to be patched. I understand that this seems to be a quite simple solution, because in the end, almost any other configuration option will be converted to either compiler or linker settings. But it's quite lowlevel and one has to dig through the Makefile in depth to extract the necessary compiler or linker options. And as you already mention, plugin Makefiles need to be patched to get it working. For example, there can nolonger be any default values in the Makefile that get always passed to the compiler as a define, as one cannot override it with a different value in Make.config. The default value has to go into the source file in case a certain define (and hence, a specific value) has not been passed to the compiler. I think that we should keep the possibility to configure highlevel plugin options from a central place like plugins.conf just as Make.config did up to VDR-1.7.33. There's also the possibility to add a Make.config to every plugin. Some plugin maintainer already started to include their own Make.config (e.g. http://projects.vdr-developer.org/git/vdr-plugin-ripit.git/tree/Make.config.template) Well, that's not what I was looking for, but kls suggested that already on vdr-portal too. I dislike on that solution that there is not a single central configuration file, but a symbolic link could do the trick to share a common file. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
Reinhard Nissl wrote: I understand that this seems to be a quite simple solution, because in the end, almost any other configuration option will be converted to either compiler or linker settings. But it's quite lowlevel and one has to dig through the Makefile in depth to extract the necessary compiler or linker options. ... so we have the same situation, we always had. You either have to find the configuration options in the Makefile or you have to find them somewhere in the documentation of the plugin, you want to build. I think that we should keep the possibility to configure highlevel plugin options from a central place like plugins.conf just as Make.config did up to VDR-1.7.33. What is your plan? Do you want to build plugins the old way inside the VDR source dir? If so, then just add your options to your Make.config as you did in the past, but prefix them with an export . Something like: export PLUGIN_OPTION = any_value This way the options reach the plugin Makefiles if you do your make plugins as the global VDR Makefile exports the value. If you don't plan to build all your plugins from the VDR source file, then a global configuration isn't needed. Then, the configuration should be part of the distribution specific package build scripts. Yours Manuel ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
I've been doing things with Make.config too, and would like it to be available again. My plugins usually followed this pattern: -include $(VDRDIR)/Make.global -include $(VDRDIR)/Make.config -include Make.config so you always had the chance to have optional control without patching makefiles. The global Make.config had lines like this: ifeq ($(PLUGIN),someplugin) ... endif to do build configuration for some plugins, or to force-off some warnings or fix certain compile issues, or even add distribution-specific quirks. (building for different debian releases from same source) So I'm in for a central method to do configuration, and not having to patch every plugin makefile and distribute several local Make.config files. Am 25.12.2012 21:07, schrieb Klaus Schmidinger: On 25.12.2012 20:47, Reinhard Nissl wrote: 1.) there is a need for a common make configuration file for both VDR and plugins. No, only for *plugins*! VDR itself will have nothing to do with this file! Should be ok to have an Make-plugin.config, as long as all vdr relevant options from Make.config get passed on into vdr.pc and can be re-read by the plugin. Directly accessing Make.config is way easier than reconstructing it, though. Speaking of all, I wonder whether some plugin out there used PREFIX or MANDIR, these are now off-limits. Oh, and by the way, with introducing $(CWD) some previously relative paths got hard coded, so moving these builds around or accessing them from different mount points might now be broken. For example, my default lib dir changed from ./PLUGINS/lib to /usr/src/pc/vdr/vdr-1.7.34/PLUGINS/lib, which only makes sense within a single virtual machine that cannot even run VDR at all. I'll have to add some overrides for that. Also, this needs some thoughts on compatibility, as I prefer to provide ONE source code package, no matter what VDR version it is for. I won't support X different plugin versions for Y different VDR versions. Don't make me choose between dropping pre-1.7.34 or post-1.7.33, you might not like the outcome. Right now, the old Makefiles luckily just do compile after all. I suggest to put the lines PLGCFG ?= /etc/vdr/plugins.conf -include $(PLGCFG) into each plugin's Makefile and that's it. Please, prettyprettyprettyplease NOT /etc. Source code should compile from within its source folder, and not interfere with global configuration. I don't want to sudo scripts that prepare sources for compiling, and I want multiple source codes in parallel to build independently, without swapping files in /etc each time. Am 26.12.2012 15:54, schrieb Manuel Reimer: then just add your options to your Make.config as you did in the past, but prefix them with an export . Something like: export PLUGIN_OPTION = any_value This way the options reach the plugin Makefiles if you do your make plugins as the global VDR Makefile exports the value. Especially for development, make plugins is waaay to heavyweight. Until now it was easily possible to enter the plugin source directory and just do an make all. (for my plugins, even a simple make will do.) Your suggestion depends on passing through VDR's makefile first to realize these options. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
I prefer to keep files for a given program together in that programs tree. Not scatter all over the computer like ms. The only thing for vdr I move is the recordings because of the space required. All settings/config files for vdr belong in the vdr directory tree. On 12/25/2012 1:07 PM, Klaus Schmidinger wrote: On 25.12.2012 20:47, Reinhard Nissl wrote: Hi, as mentioned in the VDR-1.7.34 announcement, Make.config is now gone for plugins. Make.config gave me the opportunity to control features or behavior of plugins and VDR at a central location without having the need to adjust each plugin's Makefile. For example, while developing vdr-xine, I could keep vdr-xine's Makefile in a distributable state and still control to enable some features I'd like to use in my local configuration. And when upgrading some other plugins at bugfix level (i. e. there are usually no new features and hence the config variables can stay the same), there was no need to adjust the Makefile due to the config entries in Make.config. Here is an excerpt of my Make.config for an example of the above mentioned configuration settings: #xine #VDR_XINE_VDR_HAS_TRUECOLOR_OSD = 1 VDR_XINE_SET_VIDEO_WINDOW = 1 VDR_XINE_VERIFY_BITMAP_DIRTY = 0 #burn DVDDEV=/dev/hdd ISODIR=/video #vdr BIDI=1 VFAT=1 REMOTE=LIRC LIRC_PUSHFREQ=64 # 1/s LIRC_REPEATDELAY=250 # ms LIRC_REPEATFREQ=32 # 1/s #LIRC_REPEATTIMEOUT=500 # ms #LIRC_RECONNECTDELAY=3000 # ms LIRC_PRIORITYBOOST=1 #muggle HAVE_ONLY_SERVER=1 As you can see, there is nothing like changing compiler or linker settings -- for that stuff, I really appreciate the way it is done now. In a private discussion with kls, he asked me to talk to other plugin developers too (so here we are) about that issue, so that any solution in that regard will be of broad agreement by all developers. To conclude: 1.) there is a need for a common make configuration file for both VDR and plugins. No, only for *plugins*! VDR itself will have nothing to do with this file! 2.) the file should be included in VDR's Makefile after including Make.config (maybe that idea should be dropped in favor of 5.a) as any VDR related option can be put into Make.config anyway). See 1.). 3.) the file should be included into plugin Makefiles after having set PLUGIN and VERSION to be able to have some plugin-/version-dependent configuration. Agreed. 4.) the file is optional -- maybe a template file like Make.config.template could indicate that there is something available for tuning. 5.) how do we name the file? 5.a) plugins.conf (doesn't fit perfectly for 2., to be a common file for VDR too) No need, see 1.). 5.b) Make.common 5.c) local.conf 5.d) Make.config.local 6.) where do we put the file? 6.a) kls suggested /etc/vdr at a random shot 6.b) I would like to put it next to Make.config 6.c) use pkg-config to determine path (defaults to VDRDIR) Can't we just agree on a fixed place for this file? Does it really have to be somewhere else on every system? I suggest to put the lines PLGCFG ?= /etc/vdr/plugins.conf -include $(PLGCFG) into each plugin's Makefile and that's it. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.34
Am 24.12.2012 10:39, schrieb Klaus Schmidinger: - The plugin Makefiles now have a separate 'install' target (suggested by Christopher Reimer). In order to still allow the normal building of VDR (with all plugins in its ./PLUGINS/src subdirectory, the plugin libraries in ./PLUGINS/lib and the i18n files in ./locale) the VDR Makefile checks the settings of LIBDIR and LOCDIR when building the plugins from within the VDR source directory. If these macros have their default values, then the 'install' targets of the plugins' Makefiles are called. Otherwise the 'all' targets are called and the plugins are merely built, and will have to be installed by a call to 'make install-plugins'. This now also allows a user to copy a plugin source to any directory, change into that directory and do 'make' and 'make install' to have the plugin installed to wherever the local installation of VDR expects them. This has a major downside: LIBDIR and LOCDIR have two different meanings: First, the install target for make install, second, the default search path for VDR as long as --lib and --localedir is not specified. There's no way to handle them different. So either I have a build that expects ./PLUGINS/lib to exist, or I *have* to use make install, that currently creates a total mess. (xineliboutput even tries to write outside of DESTDIR, and luckily fails to write directly to /lib/.) I'm now (after 6 hours) at the point that I'll probably have to write an own lib and locale collector script that collects what has been in ./locale and ./PLUGINS/lib before, avoiding all the Makefiles, picking the right folders and files (there's no common way to find the .so file in the src folder), renaming them, etc. And I'm starting to think whether staying at VDR-1.7.33 wouldn't be the better solution. (or returning to 1.7.31 where editing recordings doesn't take forever.) Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Debugging facility in VDR Makefile(s)?
Hello! When I had a deeper look into VDR, I wondered why there seems to be no debugging facility. I added the following to VDR's Makefile: debug: CFLAGS += -DDEBUG -ggdb3 -O0 debug: CXXFLAGS += -DDEBUG -ggdb3 -O0 debug: all ... so make debug creates an executable where no variables are optimized out and and no statements are reordered. I guess this could be useful for other people as well. Or did I miss something and this is already included somewhere? Ciao, Eike PS: Sorry, I misdirected this mail to vdr-ow...@linuxtv.org first. signature.asc Description: This is a digitally signed message part. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
