Before one could just run "make" and after that you could just run ./vdr. However, now LOCDIR is set to $(PREFIX)/share/vdr/locale by default, which causes localisation to not work unless "make install-i18n" (or "make install" which runs it as well) is run, which copies the locale files to LOCDIR.
However, almost exactly the opposite is the case with PLUGINLIBDIR, which by default is ./PLUGINS/lib so that it works inside the source-tree, but it is not so good if installed into /usr/local.
AFAICS this is inconsistent. I think either VDR should work out-of-the-box (without modifying make variables) inside the source tree *or* out of the source tree.
I.e. LOCDIR should be changed to "./locale" or PLUGINLIBDIR should be changed "$(PREFIX)/lib/vdr" or similar.
Or make the i18n.c work with locales being either in LOCDIR or ./locale.
It doesn't really matter to me, but for some other users the current state might be confusing.
On 8/19/07, Anssi Hannula anssi.hannula@gmail.com wrote:
I've already seen this problem for people who install vdr. People seem to expect that vdr is installed to /usr/local/bin while plugins go to /usr/local/bin/PLUGINS/lib. The current Makefile puts:
vdr to $(DESTDIR)$(BINDIR), plugins to $(DESTDIR)$(PLUGINLIBDIR), with DESTDIR empty by default.
ok.. so vdr goes in /usr/local/bin, as expected.. but plugins go in ./PLUGINS/lib.. Again, the most common expected behavior that I see from users is that vdr be installed to $(BINDIR) and plugins installed to $(BINDIR)/$(PLUGINLIBDIR). vdr in /usr/local/bin, plugins in /usr/local/bin/PLUGINS/lib.
Also, when cleaning plugins, shouldn't ALL copies be cleaned? Why would you clean plugins binaries from ./PLUGINS/lib but not from your install path is as well? In the previous example, /usr/local/bin/PLUGINS/lib.. It seems fitting & expected to: @-rm -f $(BINDIR)/$(PLUGINLIBDIR)/*.so.$(APIVERSION)
Just my observations...
On 08/19/07 19:13, Anssi Hannula wrote:
You're right. When I started writing VDR, the idea was to have everything in one directory and also run it from there. No "install" or anything.
Then came people who insisted in "installing" VDR, so the BINDIR etc. got in, which I didn't care about, because I just didn't do "make install". Later came the plugins, and that's when VDR actually needed to know where they are, so that's when PLUGINLIBDIR came in. I still didn't care about it, because the default was what I needed, namely ./PLUGINS.
Now with gettext, VDR needed to know where the locale files are, so it can offer the user the list of supported languages. Somehow I made the mistake of making /usr/share/vdr/locale the default for this, not thinking about the confusion this apparently causes. (Actually /usr/share/vdr/locale should probably become /usr/share/locale with the latest changes in handling this stuff in version 1.5.8).
Since I don't care the least bit about actually "installing" VDR, I should probably stay completely out of the "install" targets. Change them to whatever you like and agree on a common version here on the list (as a complete patch against the latest developer version).
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
make clean-plugins to clean up everything that 'make plugins' generated
make clean to clean up everything that 'make vdr' or 'make i18n' created
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 in order to achieve this, 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 ;-). So you can make the default for PLUGINLIBDIR and LOCDIR point to whatever location you want (and good luck finding a consensus in these defaults ;-).
If there shall be a way to remove what any "install" target has created, this shall be done in a "clean-install" or whatever target. I don't want 'make clean' to have anything to do with any "install" target.
Klaus