[Kde-extra-gear] backwards compatibility

[Klas Kalass]

Am Montag, 26. Januar 2004 18:26 schrieb Jeroen Wijnhout:
> On Monday 26 January 2004 08:27, Klas Kalass wrote:
> > > > The problem is, that the entire module cannot be compiled if there
> > > > was a MIN_CONFIG(3.1). The occasional developer should still be able
> > > > to check out the stuff in the extragear modules and fix things.....
> > >
> > >    Requiring KDE 3.2 or higher is basically never going to be
> > > acceptable for Kst.  If that happens, we will need to find alternate
> > > arrangements. If individual apps can't specify which minimum KDE
> > > version they require, maybe we need a different approach to
> > > partitioning the applications in CVS.
> >
> > Is it unacceptable that the module as checked out requires it, or is it
> > unacceptable that when doing releases, care must be taken to configure
> > your applications release for the correct KDE version?
>
> I was wondering, how do apps add their application specific configure
> checks now? Usually you would edit configure.in.in, but that would affect
> all other apps in KEG. So the problem is not just about the minimal KDE
> version, but it is really about adding application specific configure
> checks.
That is done in application specific configure.in.in files which reside in the 
app dir. K3B uses this feature heavily.

I did not experiment with different MIN_CONFIG entries in those specific 
files, the Version requirement for the module was increased without asking 
the list or me. 

If someone has time to test if things work like expected when the min config 
is moved to the amarok configure.in.in then I would be very happy about a 
short report. Thanks in advance!

>
> The problem would be solved if all the autoconf and related files would go
> in the application dir. So each application dir would have a
> configure.in.in, Makefile.am.in and Makefile.cvs ( + linked admin dir). The
> configure script in the KEG module dir will take care of calling the
> configure scripts in each and every application dir.
If the configure.in.in in the subdir works like expected that would be enough. 
We have scripts to extract an application dir and merge it with the necessary 
build system files for releases. No need to overcomplicate things.

Regards,
  Klas