[CMake] Cmake + Eclipse with a team

[Alexander Neundorf]

On Thursday 05 December 2013, David Erickson wrote:
> Hi Eric-
> Thanks for the response! See inline-
> 
> On 12/4/2013 11:17 PM, Eric Noulard wrote:
> > 2013/12/5 David Erickson <daviderickson at cs.stanford.edu>:
> >> Hi All-
> >> We would like to use cmake for our build infrastructure, and Eclipse for
> >> code editing/debugging.  I found and read
> >> (http://www.vtk.org/Wiki/Eclipse_CDT4_Generator) which worked as
> >> expected.. However, what became apparent is that anytime we update our
> >> source code working tree there is the possibility that another
> >> developer has added directories/files and/or changes the CMakeLists.txt
> >> file, rendering our Eclipse configuration out of date for the new code.
> >>  The two major limitations I see are:
> >> 
> >> 1) Having to delete the project from Eclipse, regenerate
> >> .project/.cproject, and re-import the project anytime the source code
> >> structure changes 2) Related to the above, losing any local
> >> modifications to the project configuration made after generation when
> >> regenerating it

You should not have to delete the project and reimport it.
You can "refresh" the project, this works in some cases, additionally you can 
"close" the project and open it again, this makes more cases work.

...
> >> How are other teams dealing with these problems? Problem #1 is the much
> >> larger issue I suspect, but solving both would be ideal.
> >> 
> >> As a secondary question, why doesn't the generator create a
> >> .project/.cproject in the root directory of a project,
> > 
> > The usual way for CMake to deal with that is out-of-source build:
> > http://www.cmake.org/Wiki/CMake_FAQ#Out-of-source_build_trees
> > In that case every generated bits goes into "build tree",
> > this is fine but with Eclipse which does not not support to have
> > a .project/.cproject outside source if you want to have VCS work.
> > 
> > You can workaround that by setting
> > ECLIPSE_CDT4_GENERATE_SOURCE_PROJECT to 1.
> > 
> > You can dig the CMake ML about out-of-source build and Eclipse and you'll
> > see more precisely what I am speaking of.
> 
> I think my question may not have been clear (or I am misunderstanding
> your response), lets say I have:
> 
> project A/
> -CMakeList.txt
> -build/
> -src/
> 
> When I run cmake inside the build directory, it creates the .[c]project
> files within build, which becomes the root directory of the Eclipse
> project.  Why not create the .[c]project files in the same directory as
> CMakeList.txt, but continue to put all generated output inside build/?
> That way (ideally) there would be less symlinking needed, VCS would
> work, etc etc.

Yes, I know.

Both issues you have are really deficiencies of Eclipse. :-/
I have filed tickets for both for Eclipse, but without success so far. The 
heavily plugin-based architecture of Eclipse doesn't make it easier.

IMO it shouldn't be hard to have a tag like <ActualProjectDir> in the .project 
file, which, when set, points Eclipse to the directory which it should 
consider as the project base directory, instead of the directory where the 
.project file is located.
This would fix one set of issues, e.g. the version control plugins would work 
properly, less/no need for all the symlinks, etc.
I added such a feature a few years back in KDevelop3, and recently in the 
project plugin for kate, for somebody who knows the Eclipse sources this 
actually shouldn't be that hard.

I also filed a ticket that Eclipse doesn't reload settings properly when the 
file changes, but I think it hasn't been worked on since then.

Also, Eclipse stores settings in different places, not always very logical.
E.g. some settings are stored in some binary file that project-tree it 
creates, so I (cmake) can't put these settings in the .project or .cproject 
files. :-/

It would be great if somebody could try to actually improve/fix these things 
in Eclipse.

Alex