Am 30.12.2012 12:52, schrieb Klaus Schmidinger:
- Using relative paths again when building plugins locally (by request of Udo
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
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
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.
Dipl.-Inform. (FH) Reinhard Nissl
vdr mailing list