I keep project and solution files in SCC repos, and I don't think it is a "mistake" as you put it. Things like the intellisense database, user settings etc. shouldn't be in there, but Visual Studio projects, Xcode projects, linux makefiles, etc, are fine to have in there. If you look at nearly any open source project, they'll have a separate folder for solution files for various versions of visual studio, makefiles and whatever else.

CMake is great. You could write up a project file for a shared or static library in just 2 lines of code:

project(test)
add_library(test SHARED test1.cpp test2.cpp test3.cpp)

Just replace SHARED with STATIC for static library. This simple code can be used to generate Unix makefiles, Visual Studio solution, Codeblocks project, etc. A little piece of heaven!

Quote:Original post by mightypigeon
I keep project and solution files in SCC repos, and I don't think it is a "mistake" as you put it. Things like the intellisense database, user settings etc. shouldn't be in there, but Visual Studio projects, Xcode projects, linux makefiles, etc, are fine to have in there. If you look at nearly any open source project, they'll have a separate folder for solution files for various versions of visual studio, makefiles and whatever else.

Thanks for calling that point out. I was thinking this morning that calling it a mistake is probably a bit strong, but I still think it is a mistake if you are likely to be sharing the code, especially if it is multi-platform. Those projects do contain information about dependencies within the code and how the code should be build. However, when you put that information into the .sln and .vcproj files you are locking into a concrete implementation of those relationships. If someone else using a different version of visual studio wants to work on the project they are probably going to have to modify the project or solution files. This creates the risk that they will accidentally submit those files, introducing incompatible code for others. Cmake abstracts that information away so that someone (in theory) can use whatever build system they prefer without it affecting anything in the code base. If you don't have something equivalent to cmake then you have to duplicate information (like you describe for some open source projects), which also introduces a greater chance of introducing builds errors if all the different build files are not updated.

Quote:Original post by void0
CMake is great. You could write up a project file for a shared or static library in just 2 lines of code:

project(test)
add_library(test SHARED test1.cpp test2.cpp test3.cpp)

Just replace SHARED with STATIC for static library. This simple code can be used to generate Unix makefiles, Visual Studio solution, Codeblocks project, etc. A little piece of heaven!

I wasn't too sure about cmake when I started with it this weekend, but I really like it now. There are some large mutli-platform projects I've worked on in the past where there was an ad-hoc system in place for the different build systems. How I wish we'd use cmake for that!