On Monday 28 May 2001 03:51 pm, Waldo Bastian wrote: > On Monday 28 May 2001 02:34, Bernd Gehrmann wrote: > > > Having said that, KDE 1 binaries can run run under KDE2 by installing > > > QT1, kdesupport1 and kdelibs1. Different library symbols make this > > > relatively simple (libqt -> libqt2, but an application specifically > > > linking libqt1 gets it). Theoretically the same will apply with KDE3 > > > vs KDE2, although it might be a little harder as more active IPC > > > mechanisms become popular. > > > > Reality check? Currently, applications linked with kdelibs from HEAD > > don't work simultaneously with applications linked with kdelibs 2.1. And > > that's going to become better? > > To be clear: you can't combine libs of the 2.x series. Either all your apps > use 2.1 libs or all your apps use 2.2 libs, you can't mix. > OK please explain why we decided that we can't do what you have described above and also keep in mind the following Quote from the B/C page of kde.org A library is binary compatible, if a program linked dynamically to a former version of the library continues running with newer versions of the library without the need to recompile. If a program needs to be recompiled to run with a new version of library but doesn't require any further modifications, the library is source compatible I have a program that uses kde 2.x libs that runs fine but when a user upgrades to kde 2.x+1 and my program refuses to run is that binary compatablily? I don't want to start a flame war here but can we have a definition of binary compatabilty that makes sense. The present one doesn't. Most of my programming experience has been with DOS/Windows and at least there if you had a program that ran under version X it usually would also run under version X+1 without any problem. Maybe we shoud take a clue from QT as it seems they don't have as many problem(s) kde has; a program compiled/linked under 2.2 usually works under 2.3, but a program compiled/linked under kde 2.1 as stated before might not work under 2.2. If this is a "major" task to ensure b/c then might I suggest that we add/remove some modules to KDELIBS to ensure that anything that ran under kde 2.1 should also run under 2.2. (assuming that is all it takes.) but I fear that this is not as simple as it sounds. Maybe I am naive about the current software development cycle but I don't think my suggestions ideas are not too far out of line. All I am asking for is a "stable" set of libraries to be able to develop other software. The current situation does not enable a developer to do this. Last week the program I wrote works this week (a minor version change to what my program depends on) it doesn't so I am back to learning what has changed and how to fix my program to take this into account only to be screwed again in another 2-3 weeks (or however long ) when 2.x+1 is released to find my program that I wrote successfully, no longer works. After a few times of bashing my head against the wall I will eventually decide that KDE is too "unstable" to use and decide to base my program on something else. GCC/(insert other popular library) doesn't change as often as KDE does. And IMHO that is a correct correlation KDE supplies an API that other programs try and use; but due to other program's requirements/features that API gets broken then how does one keep a program up to date? I could see this if we were just writing a single program but we are writing a "template" that other programs/programmers have to use and we should be doubly carefull that our code is not what breaks other code. > Getting KDE 2.x running besides KDE 3.x will be a daunting task. It will > put additional constraints on what we may change in KDE 3.x and I don't > like that at all. I'm inclined to say that we shouldn't support KDE 2.x > running in parallel with KDE 3.x at all. Yes, I know that sucks. The only common thread that ALL developers face is that there are only 24 hours in a day and ANYTHING that would cause something to take more time (maybe a recompile or a debug session) should be avoided. My time is probably worth less than any 2-3 other developers out there and having to recompile the "whole" kit and kaboodle just to get something that worked before someone decided to add a new feature is not the way to try and develop. Does anyone remember trying to develop KDE last year when kde and qt were changing almost daily? Yes without the changes KDE wouldn't be where it is today but think about the man-hours that were lost to hard to track down bugs (....is it my program or a library change.) Development on a "moving" target is like trying to nail jelly to a wall You might get lucky and again you might spend the next week tracking down a bug that you don't have enough information about because the libraries you developing against are changing faster. IMHO we must set some sort of failsafe ... KDE WILL always work against (insert variable number of libraries/kernels/whatever) and stick to it not say for this one we need QT 3.whatever but the exact version; and then if they release another version we can choose whether we want to support that or provide a patch against this particular update. > > Cheers, > Waldo -- Maniac@alltel.net 40° 37' 9" N, 96° 57' 24" W A single tasking guy in multi tasking world