KDevelop project fails to build with CVS

SUSE 10.1, KDE 3.5.5, KDevelop 3.3.5, Cervisia 2.4.5

[RESOLVED 10 Nov 2006]
To build successfully after moving a project, use Build >> Clean Project, followed by Build >> Run Automake & Friends and Build >> Run Config.

I’m trying to learn to use source control with KDevelop. CVS seems the most popular and most stable. I looked briefly at SVN, but the GUI tool seems immature compared with Cervisia. But I can’t get CVS and KDevelop to play nicely together.

The following steps were done:

  1. Built a local CVS root [/home/darrell/Development/CVS/CVSROOT] using Cervisia,
  2. With KDevelop, build a very simple test project using the Simple KDE Designer Project template. Assure this project will build correctly.
  3. Import the test project into CVS using Cervisia. Check the project out into the identical working directory where it was before – after renaming the old folder, so only files from CVS are present in the folder.
  4. Opened the checked out project and tried to build. The project failed to build.
  5. Run automake and Friends and Run Configure did not fix the problem.

So, is there some magical incantation that I need to do to make the project live again? With or without CVS set in Version Control options of project appears to make no difference. I set CVS as source control for project in project options, then did Automake and friends and Run Config. Build gives same result.

I would like to use CVS for keeping track of my changes. It seems clear that it should work. Cervisia and cvs appear to be working properly. But there appears to be some magic required to get a project rolling again after checking it out from CVS and it is not as simple as deleting config.status which has fixed these kinds of problems before.
Config.Status Problem Resolved.

Here is an archive of the test project: Simple Test Project Fails to Build After CVS

Thanks very much,

perhaps… KDevelop projects freak when moved.
Posted by: windyweather
Date: 9-Nov-2006 22:24

Perhaps the problem is not with CVS integration, but with the difficulty of moving a KDevelop project to another path. After some testing, if the project is checked out of CVS to exactly the same path, then the project will build correctly. In the previous case the path changed from
/home/darrell/Development/testdesignkde to

Is there a well-known formula to fix up a project after it has been moved? Clearly checking projects out from a CVS repository is not likely to leave them in exactly the same path as before and there surely is a way to resolve this.


here is the build log after checkout from CVS.
cd '/home/darrell/Development/testDesignKde/debug' && WANT_AUTOCONF_2_5="1" WANT_AUTOMAKE_1_6="1" gmake -k
gmake all-recursive
Making all in doc
Making all in .
gmake[3]: Nothing to be done for `all-am'.
Making all in en
gmake[3]: Nothing to be done for `all'.
Making all in po
gmake[2]: Nothing to be done for `all'.
Making all in src
gmake[2]: *** No rule to make target `/home/darrell/Development/testdesignkde/src/main.cpp', needed by `main.o'.
gmake[2]: *** No rule to make target `/home/darrell/Development/testdesignkde/src/testdesignkde.cpp', needed by `testdesignkde.o'.
gmake[2]: *** No rule to make target `/home/darrell/Development/testdesignkde/src/testdesignkdewidget.cpp', needed by `testdesignkdewidget.o'.
if g++ -DHAVE_CONFIG_H -I. -I/home/darrell/Development/testDesignKde/src -I.. -I/opt/kde3/include -I/usr/lib/qt3/include -I/usr/X11R6/include -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -g3 -fno-inline -O0 -g3 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -MT testdesignkdewidgetbase.o -MD -MP -MF ".deps/testdesignkdewidgetbase.Tpo" -c -o testdesignkdewidgetbase.o testdesignkdewidgetbase.cpp; then mv -f ".deps/testdesignkdewidgetbase.Tpo" ".deps/testdesignkdewidgetbase.Po"; else rm -f ".deps/testdesignkdewidgetbase.Tpo"; exit 1; fi
gmake[2]: Target `all' not remade because of errors.
gmake[1]: *** [all-recursive] Error 1
gmake: *** [all] Error 2
*** Exited with status: 2 ***