Hi Eric-
Thanks for the response! See inline-
On 12/4/2013 11:17 PM, Eric Noulard wrote:
2013/12/5 David Erickson <[email protected]>:
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
