[CMake] Cmake + Eclipse with a team

[Michael Jackson]

I used to use Eclipse for coding with CMake and the what worked the best for me was the following (This assumes you are on Unix/Linux/OSX).

Start in "Project A". Create a directory "Build". Have CMake generate "Makefiles" using "Build" as the build directory.

Start up Eclipse. Create a new "Existing Makefile" project and during the setup of that project you need to adjust the build command to "make -C ${ProjDirPath}/Build VERBOSE=1" which tells Eclipse to run make but use your already created Build directory with your makefiles.

Then Eclipse will show you the complete "file system" of Project A, VCS works, builds work (inside AND outside of Eclipse). The only downside is you get .project/.cproject in your Project A directory which you can have VCS easily ignore with a few config files. The procedure is described on the CMake wiki here

http://www.cmake.org/Wiki/CMake:Eclipse_UNIX_Tutorial  Look for "Option 2". THere are screen shots to help you through the setup.

Hope that helps.
Mike Jackson.

On Dec 5, 2013, at 3:16 AM, David Erickson <daviderickson at cs.stanford.edu> 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
>> 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
> --
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake