1

I have been taking a look at CMake for a while and I really like the idea of having code without cluttering projectfiles of several IDE's. There's just one thing I fail to understand:

You have your project with CMake files and each developing person generates his own project from it for his/her favourite IDE. But how do you nicely merge those things back into the general (CMake) project folder again? Or do you need to manually sync the changed files everytime again, by copying them in the general project folder again?

I hope you guys can help give me a solution to this problem!

  • 6
    The generated project files are build artifacts, just like object files. They aren't portable to other systems, and should never be manually modified or checked into a version control system. – Peter Jan 14 '15 at 16:34
  • 1
    @Peter And that comment should probably be an answer. To clarify: You check in the `CMakeLists.txt` files themselves to your version control system, *not* the generated IDE project files. This of course means that each of your developers has to run CMake on their own machine before they can build anything, but that is kind of the point. – ComicSansMS Jan 14 '15 at 16:59
  • 1
    I always build out of source and with completely separate source and binary trees. This keeps the generated files out of the source control. – drescherjm Jan 15 '15 at 14:42
  • Forgot to mention. Project files are generated files and exist in the build tree. Also since I need to build with more than 1 compiler I have 1 source tree and several binary trees each binary tree having its own environment with all dependencies built for that compiler 32 or 64 bit.. – drescherjm Jan 15 '15 at 14:48

1 Answers1

5

The generated project files are build artifacts, just like object files. They aren't portable to other systems, and should never be manually modified or checked into a version control system. Instead, check in the CMakeLists.txt file. Note that these generated project files refer directly to the source files, and can be used not only to build, but also to edit your source files.

Changes to the project are made directly to CMakeLists.txt (for example adding a new file, or linking to a new library). If changes are needed to support a certain development environment, you make those carefully, and test to be sure you haven't broken the build on someone else's environment. For example, IF(WIN32) or IF(UNIX) allows basic conditionals on system type. Many more are possible based on exact build tool, system architecture, presence or absence of libraries or other files, etc.

It is highly recommended to build "out-of-source", so that build artifacts (including generated project files) do not touch the source tree at all. This keeps your source control software clean, and allows multiple builds for multiple compilers out of the same source.

Peter
  • 14,559
  • 35
  • 55
  • So am I right when I say when you generate platform/IDE specific projects they shouldn't be modified anymore but only be used to build the final lib/exe? Thus: I can't work in my favourite IDE right? –  Jan 21 '15 at 14:48
  • You can *work* in your favorite IDE: write software, use the indexing functions, refactor functions, build, debug, etc. You can't adjust the project such as adding files or changing compiler flags – Peter Jan 21 '15 at 16:06
  • Think about it: if the goal is to eliminate the maintenance of multiple project files, all doing things differently, then you have to start from a common cmake file. Once you start modifying the generated project file and expecting it to be permanent, then what's difference from the original state of having a pile of different project files for different IDEs? – Peter Jan 21 '15 at 16:10
  • In fact, cmake ties directly in with the build functions of many IDEs, so that when you modify the CMakeLists.txt file to, for example, add a new source file, an IDE build will trigger a regeneration of the project files. – Peter Jan 21 '15 at 16:13
  • I am sorry if I am a bit slow on the uptake. I understand that you have one source where you generate builds from. Since all options are specified in the CMake build you can't (or at least shouldn't) edit them in the IDE. So far so good I hope! But still this part I don't understand: You generate your build (for example for Visual Studio) in a different directory so the changes you make with Visual Studio only appear in the generated directory (so not the general CMake directory). Then what are the best practises of merging those together again? Or do I miss a point? –  Jan 25 '15 at 16:01
  • 1
    Oh, I see the problem. It is only the project file itself that lives in the build directory. That project file references the source files in their original location. Editing that source code from Visual Studio edits the original source. No merging needed. – Peter Jan 26 '15 at 02:45
  • Aha! Okay thanks! That explains a lot!:P Accepting your answer! –  Jan 26 '15 at 15:30