If you look in the ./configure output of kdevelop you'll see that it looks for the file "cvsservice_stub.h" provided by kdesdk >= 3.3 (the old version have th files but the API was enanched and the needed function isn't provided=> compilation error). So if kdesdk is not installed kdevelop will be not build will all the plugins enabled. For more info take a look at the configure.in.in file. I'll suggest to add another use flag like, for example, "cvs", if it's enabled then >=kdesdk-3.3.0 will be added like dependencie. Let me know if you like that I'll provide a modified ebuild. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 39200 [details, diff] simple patch that adds the "cvs" useflag and then the deps on >=kde-base/kdesdk-3.3.0 I don't know it it's better "cvs" or "cvsservice"
>(the old version have th files but the API was enanched and the needed function isn't provided=> compilation error). I installed KDevelop with KDE 3.2 before switching to 3.3 and it compiled fine for me!?
Strange, did you had kdesdk when you compiled kdevelop? and the was cvsservice plugin compiled? If you look at /usr/kde/3.2/include/cvsservice_stub.h you'll see this declaration for function checkout: virtual DCOPRef checkout( const QString& workingDir, const QString& repository, const QString& module, const QString& tag, bool pruneDirs ); Then the 3.3 version has 2 declarations: virtual DCOPRef checkout( const QString& workingDir, const QString& repository, const QString& module, const QString& tag, bool pruneDirs ); virtual DCOPRef checkout( const QString& workingDir, const QString& repository, const QString& module, const QString& tag, bool pruneDirs, const QString& alias, bool exportOnly ); the last one is needed by kdevelop-3.1.0 or you'll get this error compiling cvspartimp.cpp: cvspartimpl.cpp: In member function `virtual bool CvsServicePartImpl::checkout()': cvspartimpl.cpp:368: error: no matching function for call to `CvsService_stub:: checkout(QString, QString, QString, QString, bool, const char[1], bool)' /usr/include/kde/cvsservice_stub.h:27: error: candidates are: virtual DCOPRef CvsService_stub::checkout(const QString&, const QString&, const QString&, const QString&, bool) because in kdesdk-3.2 the second checkout declaration doesn't exists.
>Strange, did you had kdesdk when you compiled kdevelop? and the was cvsservice plugin compiled? >If you look at /usr/kde/3.2/include/cvsservice_stub.h Unfortunately I'm a bit low on diskspace, so kde 3.2 is gone and even /var/log/portage/ cleaned in between.. *grmph* I need to free another partition. I didn't tested if cvs worked within kdevelop, but all versions from kdevelop-3.1_beta1 to final compiled fine for me under KDE 3.2
forgot: kdesdk was installed, of course. Do you have KDE 3.2/3.3 running parallel?
By now like every kde developer, I'm using kde from CVS. But I have the tbz2 of the old version of kde, and I installed them and I get the above reported error with kdesdk-3.2. BTW, if it works or not works with kdesdk-3.2, can you agree that this new entry is needed?
I did not look at the code/Makefiles Simone and I'm neither a KDE nor C++ developer. What I do know is the following: It is officially announced to be KDE 3.2 compatible and compiled fine for me. I also know, that non kdebase/* ebuilds always compile against the newest /usr/kde/x.y (see set-kdedir() in kde-functions.eclass). May it be, that there is some of this C/++ style #ifdef kde-x.y makro stuff, which conflicts with the behaviour of the eclass?
Looking at the code there's nothing related to any #ifdef, I know that it will be compatible with kde 3.2 but this seems to not happen with this plugin. Someone reported this with kdesdk-3.2.3 but there were no answer. http://lists.kde.org/?l=kdevelop&m=109295728521987&w=2 The file cvsservice_stub.h is generated by the dcop metacompiler and I make a lot of tries but it's generated without the needed function (a simple configure and make in the kdesdk-3.2.3/cervisia/cvsservice dir will create it). By the way, I think that the patch to the ebuild MUST be added, probably removing the need for >=kdesdk-3.3.0 with >=kdesdk-3.2.0, because it's not good to not have the cvsservice plugin. Do you think will be better the "cvs" useflag or the "cvsservice"? Then if someone will report compilation problem related to cvspartimpl.cpp with kdesdk-3.2.X at least we'll have an explanation.
forcing kde 3.3. now
