[Kde-extra-gear] backwards compatibility

[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.

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. 

I'm a complete autotools n00b, so perhaps this is not possible. However, it 
would resolve all problems once and for all, or?

To assist n00bs like me, we could even consider putting some default 
configure.in.in, Makefile.am.in, Makefile.cvs (and whatever more is 
necessary) in CVS, just like we do with the admin directory.

best,
Jeroen

-- 
Kile - an Integrated LaTeX Environment for KDE
http://kile.sourceforge.net