[vdr] [ANNOUNCE] VDR developer version 1.7.35
rnissl at gmx.de
Mon Dec 31 14:38:21 CET 2012
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.
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl at gmx.de
More information about the vdr