[vdr] [ANNOUNCE] VDR developer version 1.7.35

[Reinhard Nissl]

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 at gmx.de