[vdr] Re: VDR and 2.6.0-test1?

[Rene Bartsch <ml@bartschnet.de>]

Am Don, 2003-07-24 um 23.32 schrieb Klaus Schmidinger:
> Rene Bartsch wrote:
> > 
> > ...
> > > > Well as vdr relies anyway on DVB API 3 it would be usefull to add the headers
> > > > to the vdr package. This way I would not need to add DVB/ tree in parallel to
> > > > vdr source. As there is no real need for the way now as far as i have
> > > > understood, it would make things cleaner IMHO. This way f.e. building RPMs
> > > > would be easier (a bit at least).
> > >
> > > I don't think it is a good idea if an application contains the header
> > > files of a driver or any other library module.
> > 
> > I'm not talking of headers, etc. A program should include all the
> > necessary code itself to be compiled against an API. Any change of the
> > driver code could break compiling of the program. If no other way it
> > would be an alternative to compile against hernel-headers as they
> > shouldn't change much, but I don't like software with such a lot
> > dependencies. Have you never been driven crazy as you had to install 13
> > proggies and libraries to get a 50 kbyte code running?
> > 
> > My suggestion is to move the necessary code of the drivers to compile
> > VDR into VDR and incorporate it in the next structural changes.
> 
> I don't think this makes _any_ sense!!
> The driver is the driver is the driver!!
> VDR is _one_ application that uses the driver - IMO it makes absolutely no sense
> at all to include _anything_ from the driver into VDR's distribution archive!
> 

I'm only talking about the necessary code for VDR to handle the API (I
don't think you want to rewrite that code by your own for VDR). In my
understanding, a API is a interface between a lower level - the hardware
driver - and a upper level - the userspace software (VDR). Driver and
userspace software should only communicate by that well defined API and
be of NO dependancy from each other (which includes not sharing code. So
the driver is the driver and userspace software is userspace software).

> Of course you can create your own VDR archive that does this - I for one
> won't make it that way.
> 
> > > Having DVB in parallel to VDR is just a suggestion (it's the way I have it).
> > > You can simply change the line
> > >
> > > DVBDIR   = ../DVB
> > >
> > > in your Make.config file to change this.
> > 
> > By the way - what about updating VDR and Makefiles to handle the path
> > for the plugin-libraries. VDR should look for plugins in the default
> > library-path of the distribution and Makefiles should install/remove
> > libraries into/from the default library-path of the distribution.
> 
> I don't want to make VDR dependent on any special Linux distribution.
> If you want to make a distribution specific VDR archive (that may also
> contain parts of the driver, if you wish), feel free to do so.

I only do like generic solutions. That's why I'm asking wether there is
a enviroment variable which points to the library path in any distro and
can be used to install/uninstall the plugin libraries.

-- 
Rene Bartsch
Faculties MNI
Computer Science 8th Semester
FH Giessen/Friedberg, Germany

Facsimile/Phone: +49 7 00/72 27 87 24
Mail:  rene@bartschnet.de



-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.