Hi, Am 30.12.2012 12:52, schrieb Klaus Schmidinger:
- Using relative paths again when building plugins locally (by request of Udo Richter).
In compatibility mode, relative paths seem to be not a good idea. The reason is that for example LIBDIR gets passed as an argument to make (e. g. ../../lib) which cannot be changed anymore within the plugin's Makefile without specifying the override keyword.
For example a single plugin used to build sublibraries in subdirectories. The Makefile to build those sublibraries contained LIBDIR=../../../../lib, but in 1.7.35 it used ../../lib and failed until I added override as mentioned above.
- Re-enabled building plugins that still use pre-version-1.7.34 Makefiles. The file Make.global is present again to satisfy the "include" these Makefiles do, but the file itself contains no settings. The VDR Makefile's "plugins" target determines whether a particular plugin uses an old style Makefile and calls it accordingly. Note that this only works when building plugins from within the VDR source tree, using "make plugins" in the VDR source directory.
In compatibility mode, Make.config gets included by the old plugin Makefiles if it exists. Make.config relies on $(CWD) being defined, but that is only true in VDR's Makefile. Hence, some variable definitions degrade to absolute paths in the root file systems and plugins fail to build.
As a workaround I've added CWD=$(VDRDIR) to Make.global as Make.global is usually included by old plugin Makefiles too in front of Make.config.
Finally, as a make in VDR's source directory always installs the plugins with new Makefile I wonder if it wouldn't be a good idea to add -p to the install command to preserve the build file times of the plugins.
Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@xxxxxx _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
