Hi there!
I now switched the ebuilds to use make install. But for that to work I needed to modify the Makefile.
install-i18n.diff Lets install target call install-i18n target.
makefile-destdir.diff: It add variable DESTDIR to makefile to install under $(DESTDIR) instead of / It also adds variable CONFDIR (by default identical to $(VIDEODIR)) to be able to set it to different value. Additionally it installs svdrpsend.pl
makefile-install-header.diff: It adds an install-header target which is also called by target install. This installs the header files and Make.config to $(HEADERDIR) (should that be changed to INCDIR ?) to be able to compile plugins against the installed vdr without the need to keep vdr sources.
Matthias
2007/8/13, Matthias Schwarzott zzam@gentoo.org:
install-i18n.diff
I already posted this to the list yesterday.
makefile-destdir.diff: It add variable DESTDIR to makefile to install under $(DESTDIR) instead of / It also adds variable CONFDIR (by default identical to $(VIDEODIR)) to be able to set it to different value.
Where gets DESTDIR actually set?
Regards, Joachim.
On Montag, 13. August 2007, Joachim Wilke wrote:
2007/8/13, Matthias Schwarzott zzam@gentoo.org:
install-i18n.diff
I already posted this to the list yesterday.
makefile-destdir.diff: It add variable DESTDIR to makefile to install under $(DESTDIR) instead of / It also adds variable CONFDIR (by default identical to $(VIDEODIR)) to be able to set it to different value.
Where gets DESTDIR actually set?
When you do make install DESTDIR=/directory/I/want/vdr/installed/to
else DESTDIR remains unset and "make install" behaves as always.
The ebuilds do this for example to satisfy some security by using a sandbox for compiling and installing programs. make install then uses some temporary image directory. After that the content gets merged to the live system. (Also preserving configuration files in that process, ...)
Matthias
2007/8/13, Matthias Schwarzott zzam@gentoo.org:
The ebuilds do this for example to satisfy some security by using a sandbox for compiling and installing programs. make install then uses some temporary image directory. After that the content gets merged to the live system. (Also preserving configuration files in that process, ...)
Ah okay, now its clear to me, thank you.
Regargs, Joachim.
Matthias Schwarzott wrote:
makefile-destdir.diff: It add variable DESTDIR to makefile to install under $(DESTDIR) instead of /
I would prefer something like DESTDIR=/usr/local that can be redirected to /usr or /tmp/newpackage/usr or similar, just as many configure scripts do it. On the downside, this wouldn't work for $(DESTDIR)$(VIDEODIR).
Cheers,
Udo
Udo Richter wrote:
Matthias Schwarzott wrote:
makefile-destdir.diff: It add variable DESTDIR to makefile to install under $(DESTDIR) instead of /
I would prefer something like DESTDIR=/usr/local that can be redirected to /usr or /tmp/newpackage/usr or similar, just as many configure scripts do it. On the downside, this wouldn't work for $(DESTDIR)$(VIDEODIR).
the usual convention is PREFIX, which defaults to '/usr/local' and can be changed to eg '/usr/' or '/sw/vdr-1.6.0' etc. DESTDIR is completely independent -- it adds _another_ prefix; this is used eg when building packages. So "make install DESTDIR=/tmp/BLD-38746 PREFIX=/sw/vdr-1.6.0" means to assume the program will be installed in /sw/vdr-1.6.0 (and look for config files in /sw/vdr-1.6.0/etc/, binaries in /sw/vdr-1.6.0/bin/ etc), but to copy all the files to /tmp/BLD-38746/sw/vdr-1.6.0. This way you can build a package w/o disturbing the /sw/ tree and install using a package manager later.
On Dienstag, 14. August 2007, Artur Skawina wrote:
Udo Richter wrote:
Matthias Schwarzott wrote:
makefile-destdir.diff: It add variable DESTDIR to makefile to install under $(DESTDIR) instead of /
I would prefer something like DESTDIR=/usr/local that can be redirected to /usr or /tmp/newpackage/usr or similar, just as many configure scripts do it. On the downside, this wouldn't work for $(DESTDIR)$(VIDEODIR).
the usual convention is PREFIX, which defaults to '/usr/local' and can be changed to eg '/usr/' or '/sw/vdr-1.6.0' etc. DESTDIR is completely independent -- it adds _another_ prefix; this is used eg when building packages. So "make install DESTDIR=/tmp/BLD-38746 PREFIX=/sw/vdr-1.6.0" means to assume the program will be installed in /sw/vdr-1.6.0 (and look for config files in /sw/vdr-1.6.0/etc/, binaries in /sw/vdr-1.6.0/bin/ etc), but to copy all the files to /tmp/BLD-38746/sw/vdr-1.6.0. This way you can build a package w/o disturbing the /sw/ tree and install using a package manager later.
I updated the patch to use DESTDIR and PREFIX.
Comments on installing header files and Make.config? Should Make.config go to $PREFIX/share/vdr ?
Matthias
On 08/13/07 18:30, Matthias Schwarzott wrote:
... makefile-install-header.diff: It adds an install-header target which is also called by target install. This installs the header files and Make.config to $(HEADERDIR) (should that be changed to INCDIR ?) to be able to compile plugins against the installed vdr without the need to keep vdr sources.
This doesn't make sense, because a plugin's Makefile does
VDRDIR = ../../.. ... APIVERSION = $(shell sed -ne '/define APIVERSION/s/^.*"(.*)".*$$/\1/p' $(VDRDIR)/config.h)
Klaus
On Mittwoch, 15. August 2007, Klaus Schmidinger wrote:
On 08/13/07 18:30, Matthias Schwarzott wrote:
... makefile-install-header.diff: It adds an install-header target which is also called by target install. This installs the header files and Make.config to $(HEADERDIR) (should that be changed to INCDIR ?) to be able to compile plugins against the installed vdr without the need to keep vdr sources.
This doesn't make sense, because a plugin's Makefile does
VDRDIR = ../../.. ... APIVERSION = $(shell sed -ne '/define APIVERSION/s/^.*"(.*)".*$$/\1/p' $(VDRDIR)/config.h)
Sure one needs to point the plugin to the place where it can find the needed files. But I have not tried to find the minimal required changeset.
Matthias
Matthias Schwarzott wrote:
On Mittwoch, 15. August 2007, Klaus Schmidinger wrote:
On 08/13/07 18:30, Matthias Schwarzott wrote:
... makefile-install-header.diff: It adds an install-header target which is also called by target install. This installs the header files and Make.config to $(HEADERDIR) (should that be changed to INCDIR ?) to be able to compile plugins against the installed vdr without the need to keep vdr sources.
This doesn't make sense, because a plugin's Makefile does
VDRDIR = ../../.. ... APIVERSION = $(shell sed -ne '/define APIVERSION/s/^.*"(.*)".*$$/\1/p' $(VDRDIR)/config.h)
Sure one needs to point the plugin to the place where it can find the needed files. But I have not tried to find the minimal required changeset.
Have a look at the SUSE vdr package. It installs headers and Make.config into /usr/include/vdr. When compiling plugins you have to use "make VDRDIR=/usr/include/vdr LIBDIR=/usr/lib/vdr all".
cu Ludwig
While we're on the topic of adjusting the Makefile.. I propose the following change to install-plugins:
old: @cp --remove-destination $(PLUGINDIR)/lib/lib*-*.so.$(APIVERSION) $(PLUGINLIBDIR)
new: @cp --remove-destination $(PLUGINDIR)/lib/*.$(APIVERSION) $(PLUGINLIBDIR)
The difference is copying *.$(APIVERSION) rather then lib*-*.so.$(APIVERSION). The reason is because not all plugins use the same naming (softdevice for example) and this minor adjustment would eliminate the need to edit the Makefile for this with every new version of vdr, or having to manually copy them to the install dir. Also I see no reason against it since we keep the APIVERSION.
And also the following change to clean-plugins:
old: @-rm -f $(PLUGINDIR)/lib/lib*-*.so.$(APIVERSION)
new: @-rm -f $(PLUGINDIR)/lib/*.$(APIVERSION) @-rm -f $(PLUGINLIBDIR)/*.$(APIVERSION)
Again using *.$(APIVERSION) instead of lib*-*.so.$(APIVERSION), and also if we're going to clean plugins from the source dir, it seems fitting to clean the installed ones as well since it's the expect behavior from most users I've observed.
These two minor changes resolve problems that are experienced by many users. Those problems being vdr not running because of missing plugin binaries because not all of them were copied during install-plugins (the inquiries about this are endless). And users having a ton of old plugin binaries left in their install dir even after 'cleaning'.
Sure the authors of plugins, if they can be contacted, can be hassled to change the file naming, and people can be taught to manually remove plugin binaries...but why not just make a couple small changes to the system that eliminates the problem? Seems like win-win to me.
Other opinions are welcome. Thanks!
Quoting VDR User:
While we're on the topic of adjusting the Makefile.. I propose the following change to install-plugins:
old: @cp --remove-destination $(PLUGINDIR)/lib/lib*-*.so.$(APIVERSION) $(PLUGINLIBDIR)
new: @cp --remove-destination $(PLUGINDIR)/lib/*.$(APIVERSION) $(PLUGINLIBDIR)
The difference is copying *.$(APIVERSION) rather then lib*-*.so.$(APIVERSION). The reason is because not all plugins use the same naming (softdevice for example) and this minor adjustment would eliminate the need to edit the Makefile for this with every new version of vdr, or having to manually copy them to the install dir. Also I see no reason against it since we keep the APIVERSION.
Which libs of softdevice are not matched by the "old" style ?
Softdevice targets usually are:
TARGETS = libvdr-$(PLUGIN).so
and (with subplugins): TARGETS += lib$(PLUGIN)-xv.so TARGETS += lib$(PLUGIN)-dfb.so
which are finally installed to:
@cp $(CPOPTS) $@ $(LIBDIR)/$@.$(APIVERSION)
And this should be match by : "lib*-*.so.$(APIVERSION)"
And also the following change to clean-plugins:
old: @-rm -f $(PLUGINDIR)/lib/lib*-*.so.$(APIVERSION)
new: @-rm -f $(PLUGINDIR)/lib/*.$(APIVERSION) @-rm -f $(PLUGINLIBDIR)/*.$(APIVERSION)
Again using *.$(APIVERSION) instead of lib*-*.so.$(APIVERSION), and also if we're going to clean plugins from the source dir, it seems fitting to clean the installed ones as well since it's the expect behavior from most users I've observed.
Stefan Lucke
When I started writing VDR, I wanted to have things simple and straightforward. Therefore everything went into one directory, and VDR was also run from within that directory. This is pretty much still how I do things today, because I want to have several versions of VDR in parallel and never actually "install" it.
I see that there is apparently a demand for actually "installing" VDR and spreading it's files into various different places, so I don't want to stand in anybody's way.
The only request I have is that it must be possible to unpack VDR into a directory and do
make vdr to compile the vdr executable into this directory
make i18n to build VDR's i18n files into ./locale
make plugins to compile all plugins under ./PLUGINS/src and have their *.so files end up in ./PLUGINS/lib, and also have their i18n files end up in ./locale
VDR must be runnable from within its source directory and must search for plugin files in ./PLUGINS/lib and for locale files in ./locale.
If it is necessary to add something like LOCAL=1 to the make calls, that's fine with me (this should, however, also be definable in Make.config - I don't want to have to add this every time I make VDR ;-).
If these basic demands are met, I don't care what any "install" targets actually do, and where they spread all the files into. So I will therefore accept any patches to Makefile, newplugin and Make.config.template that mess around with the "install" targets.
I have copied the latest versions of these files to
ftp://ftp.cadsoft.de/vdr/Developer/Makefile.tgz
so that people who want to change things can use them.
Please try to keep the changes to 'newplugin' at a minimum, though, so that plugin authors won't have too much to adapt.
Klaus
On Wed, 2007-08-15 at 18:55 +0200, Ludwig Nussel wrote:
Have a look at the SUSE vdr package. It installs headers and Make.config into /usr/include/vdr. When compiling plugins you have to use "make VDRDIR=/usr/include/vdr LIBDIR=/usr/lib/vdr all".
it always strikes me, that vdrs build process is rather limiting. you can not just download a plugin unpack, build and install it. no, you have to first find your vdr source, unpack it to the right path, rename or link it correctly, then go to the vdr main dir and do make plugins, filling the screen with output of plugins you already compiled. most plugins even don't allow to be compiled from within its own root as they use the default Makefile.
the way it should be IMHO is "make; make install" should build and install vdr (in $(PREFIX)/bin) and all plugins (in $(PREFIX)/lib/vdr) that are within PLUGINS/src/ and install vdrs headers in $(PREFIX)/include/vdr. additionally there should be a vdr.pc for plugins to use to get all needed info for building outside of vdrs source (most important CFLAGS).
best regards ... clemens
-
Artur Skawina -
Clemens Kirchgatterer -
Joachim Wilke -
Klaus Schmidinger -
Ludwig Nussel -
Matthias Schwarzott -
Stefan Lucke -
Udo Richter -
VDR User