[CMake] Cmake + Eclipse with a team

[Eric Noulard]

2013/12/5 David Erickson <daviderickson at cs.stanford.edu>:
> 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?

May be, I don't know.
I don't use this scheme, currently I always have single eclipse project.

>>> 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 and that the purpose of "ECLIPSE_CDT4_GENERATE_SOURCE_PROJECT"
which makes CMake generate the .[c]project files
in the source tree and not in the build tree (as it is usually done).

This is a workaround because Eclipse is not able to handle out-of-source
project files.


-- 
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org