When you import an existing subversion project on your hard-drive into Eclipse, it sometimes does not recognize that the project is already version controlled. I fixed this by right-clicking on the project folder and selecting ‘Share’. It then automatically detects that the project is already shared (i.e. under SVN control) and just fixes the configuration.

Sometimes, subversion screws up big time when a commit in process fails. It might then ask you to run

svn cleanup

to remove all locks from directories that could not be unlocked due to the sudden commit failure. So like all good people, you follow instructions and run svn cleanup. But, in all its stupidity, the cleanup command failes because it itself can’t acquire a lock!

Here’s the fix: run

svn status

in the top-level directory; every directory with “L” (locked) status needs to be cleaned up. So, starting at the leaf of the directory tree working your way upwards, enter each directory and run svn cleanup. Apparently, svn cleanup did not work for me if there was a locked directory somewhere underneath the folder I ran the command in. Yeah, stupid, I know, switch to Git and avoid the hassle of subversion’s inconsistent failures.

From here:

If you want to remove an Eclipse workspace, here is how you do it.

1. Close Eclipse
2. Delete the “.metadata” folder from the the workspace you want to delete.
3. Find this file: C:\Program Files\eclipse\configuration\.settings\org.eclipse.ui.ide.prefs
4. Delete the workspace reference and save.

This post addresses some issues with using CMake in Eclipse. CMake is a cross-platform build system that I have found to be a good substitute for Autotools. Although CMake provides considerable support for using it as a build system for Eclipse projects, it has one big shortcoming: There is no support for version control within Eclipse if the build directory is separate from the source directory of the project. For more details about this issue, see Option 1 of the CMake: Eclipse UNIX Tutorial.

To allow our project to have a separate source and build directory, while enabling support for CMake and version control from within Eclipse, we will do the following:

1. We will first get sources of the project from a SVN repository in a top level ‘src’ folder
2. We will use CMake to generate Makefiles, and Eclipse project configuration files in the ‘src’ folder
3. We will then delete all the Makefiles and CMake cache files, but leave the Eclipse project configuration files in place
4. We will create a separate ‘build’ directory to compile our sources
5. We will regenerate the Makefiles for sources in this ‘build’ directory using CMake
6. We will import the sources as a single project in Eclipse
7. We will tell Eclipse to build our project in the ‘build’ directory rather than the ‘src’ directory
8. Finally, we will work with Eclipse as usual

Ok, let’s begin.

1. Getting the sources of your (not yet) Eclipse project from SVN: I’ll let you do this on your own and assume that the sources have been placed in a folder named ‘src’.
2. Generating Makefiles: CMake is not a replacement for Makefiles. It allows you to simply generate Makefiles for your project. You need to provide CMake with some build information (in a file called CMakeLists.txt) and it will do the rest. For example, you can tell CMake which sources must be used to build which executable, without worrying about dependencies etc. Here is a sample CMakeLists.txt file:

project (tpm_integrity)   cmake_minimum_required(VERSION 2.6)   # Lets you see the command executed by make #set(CMAKE_VERBOSE_MAKEFILE true)   set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${tpm_integrity_BINARY_DIR}/lib) set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${tpm_integrity_BINARY_DIR}/lib) set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${tpm_integrity_BINARY_DIR}/bin)   include_directories( ${tpm_integrity_SOURCE_DIR}/common )   link_directories( )   set(DEBUG_DEFINES #RPC_DEBUG=1 #TPM_DEBUG=1 )   set(RELEASE_DEFINES #DO_MCAST=1 )   set(SRCS common/TPMRPC.cpp common/tpm_msg_lib.c common/listener.c common/listener_long_msg.c integrityMain.cpp )   add_executable(aggregator ${SRCS} )   set_target_properties( aggregator PROPERTIES COMPILE_DEFINITIONS_DEBUG "${DEBUG_DEFINES}" COMPILE_DEFINITIONS "${RELEASE_DEFINES}" COMPILE_FLAGS "-Wall -static" )

Given this sort of information Cmake can easily generate a Windows Makefile or a Unix Makefile with the help of a ‘generator’. In our case, we will use a special generator called the ‘Eclipse CDT4 Generator’ and not only create a Unix Makefile, but also the Eclipse project configuration files.

$ cd src $ cmake -G"Eclipse CDT4 - Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug .

3. Deleting all CMake generated files except the Eclipse project configuration files: In step 2, CMake should have created two files that Eclipse recognizes as project configuration files: ‘.project’ and ‘.cproject’, Makefiles, and a bunch of other files and directories that are needed by CMake. Since we don’t want to build our project in the ‘src’ directory we will delete the CMake generated files from ‘src’ and recreate them in a new ‘build’ directory.

# make sure you are in the 'src' directory $ find -name 'CMakeFiles' -prune -or -name 'cmake_install.cmake' -or -name 'CMakeCache.txt' -or -name 'Makefile' | xargs rm -rf

4. Create a new ‘build’ directory. This is simple.

$ cd ../ $ mkdir build

5. Regenerate Makefiles

$ cd build $ cmake -i ../src

Notice that this time we did not specify a generator. Why? Because we want CMake to use the default generator (i.e. for UNIX Makefiles) rather than the one for Eclipse CDT.

6. Import sources as a single project in Eclipse: Open Eclipse, click File->Import->Existing Project Into Workspace (Keep the Copy projects into workspace box unchecked.)
7. Tell Eclipse to build project in the ‘build’ directory: Select Project->Properties->C/C++ Make Project. Change the value of the Build directory field to the path to your build directory.
8. And you’re all done.