[CMake] Cmake + Eclipse with a team

David Erickson daviderickson at cs.stanford.edu
Thu Dec 5 03:16:59 EST 2013


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
> When I want that I do not use Eclipse CDT generator
> I use plain Makefile/Ninja generator and configure my own CDT project by hand.
> .project/.cproject go into the source tree whereas the generated bits goes
> into a separate build dir (usually <src>/build)

This sounds like it could be a good option, although I am wondering how 
it works when you would also like to build dependent  shared libraries?  
For example, my directory structure looks like:

Top Level Directory/
-project A/
-- ...
-library B/
-- ...
-library C/
-- ...

A depends on B, and B depends on C, each have their own CMakeList.txt 
file, and A's contains an add_subirectory call for B, and B similarly 
has the same function call for C.  I'm assuming I would want three 
different top level Eclipse projects, one each for A, B, and C, and it 
seems like this could be tricky to set up properly?

>
>> 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.

>
>
>> but just put all
>> temporary/build data inside a build subdirectory - and create separate
>> projects for each subdirectory?
> Separate project for each subdir ? I don't think I get what you want.

See my top inline response, hopefully it makes it more clear, if not let 
me know.

Thanks!
David


More information about the CMake mailing list