[Kde-extra-gear] backwards compatibility

[Jesper K. Pedersen]

I talked to David Faure about this, and if I understand him correct, then
each of the configure.in.in are concatenated into one configure.in for the
whole kdeextragear-2 module.

As MIN_CONFIG states a minimum KDE version, then having that in several
configure.in.in would simply result in a conflict.

Cheers
Jesper.

Klas Kalass <klas.kalass at gmx.de> writes:

| 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
| 
| _______________________________________________
| Kde-extra-gear mailing list
| Kde-extra-gear at kde.org
| https://mail.kde.org/mailman/listinfo/kde-extra-gear
| 

-- 
Jesper K. Pedersen          |  Klarälvdalens Datakonsult
Senior Software Engineer    |  www.klaralvdalens-datakonsult.se
Peder Skrams Gade 27 3. tv. |
6700 Esbjerg                |  Platform-independent
Denmark                     |  software solutions