change make install to be really useful

  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 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!
  

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
  

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