I am working on an open source C++ project, for code that compiles on Linux and Windows. I use CMake to build the code on Linux. For ease of development setup and political reasons, I must stick to Visual Studio project files/editor on Windows (I can't switch to Code::Blocks, for example). I see instructions to generate Visual Studio files using CMake, as here.
我正在开发一个开源c++项目，用于在Linux和Windows上编译代码。我使用CMake在Linux上构建代码。为了便于开发设置和政治原因，我必须坚持使用Windows上的Visual Studio项目文件/编辑器(例如，我不能切换到代码::Blocks)。我看到使用CMake生成Visual Studio文件的说明，如这里所示。
Have you used CMake to generate Visual Studio files before? How has been your experience? Suppose I want to add a new file to my project. What is the workflow for this?
您以前使用过CMake来生成Visual Studio文件吗?你的经历怎么样?假设我想向我的项目添加一个新文件。这个的工作流程是什么?
8 个解决方案
#1
53
CMake is actually pretty good for this. The key part was everyone on the Windows side has to remember to run CMake before loading in the solution, and everyone on our Mac side would have to remember to run it before make.
CMake其实很好。关键是Windows操作系统的每个人在载入解决方案之前都必须记住运行CMake，而Mac操作系统的每个人都必须记住在make之前运行它。
The hardest part was as a Windows developer making sure your structural changes were in the cmakelist.txt file and not in the solution or project files as those changes would probably get lost and even if not lost would not get transferred over to the Mac side who also needed them, and the Mac guys would need to remember not to modify the make file for the same reasons.
最困难的部分是作为Windows开发人员，确保您的结构更改在cmakelist中。txt文件,而不是在解决方案或项目文件,这些变化可能会迷路,即使不会丢失不会得到转移到Mac也需要他们,和Mac的家伙需要记住不要修改文件同样的理由。
It just requires a little thought and patience, but there will be mistakes at first. But if you are using continuous integration on both sides then these will get shook out early, and people will eventually get in the habit.
这只需要一点思考和耐心，但一开始就会出错。但是如果你在两边都使用连续的积分，那么这些就会被提前打乱，人们最终会养成这个习惯。
#2
37
Not sure if it's directly related to the question, but I was looking for an answer for how to generate *.sln from cmake projects I've discovered that one can use something like this:
不确定它是否与问题直接相关，但我正在寻找如何生成*的答案。来自cmake项目的sln，我发现人们可以使用这样的东西:
cmake -G "Visual Studio 10"
The example generates needed VS 2010 files from an input CMakeLists.txt file
该示例从输入CMakeLists生成所需的VS 2010文件。txt文件
#3
26
We moved our department's build chain to CMake, and we had a few internal roadbumps since other departments where using our project files and where accustomed to just importing them into their solutions. We also had some complaints about CMake not being fully integrated into the Visual Studio project/solution manager, so files had to be added manually to CMakeLists.txt; this was a major break in the workflow people were used to.
我们将我们部门的构建链转移到CMake，并且自从其他部门使用我们的项目文件并习惯于将它们导入到他们的解决方案之后，我们有了一些内部障碍。我们也有一些关于CMake没有完全集成到Visual Studio项目/解决方案管理器中的抱怨，因此文件必须手动添加到CMakeLists.txt中;这是人们习惯的工作流程中的一个重大突破。
But in general, it was a quite smooth transition. We're very happy since we don't have to deal with project files anymore.
但总的来说，这是一个相当平稳的过渡。我们很高兴，因为我们不用再处理项目文件了。
The concrete workflow for adding a new file to a project is really simple:
向项目添加新文件的具体工作流程非常简单:
- Create the file, make sure it is in the correct place.
- 创建文件，确保它在正确的位置。
- Add the file to CMakeLists.txt.
- 将该文件添加到CMakeLists.txt。
- Build.
- 构建。
CMake 2.6 automatically reruns itself if any CMakeLists.txt files have changed (and (semi-)automatically reloads the solution/projects).
CMake 2.6自动重新运行，如果有任何CMakeLists。txt文件已经更改(和(semi-)自动重新加载解决方案/项目)。
Remember that if you're doing out-of-source builds, you need to be careful not to create the source file in the build directory (since Visual Studio only knows about the build directory).
请记住，如果您正在进行源代码外的构建，您需要小心不要在构建目录中创建源文件(因为Visual Studio只知道构建目录)。
#4
10
As Alex says, it works very well. The only tricky part is to remember to make any changes in the cmake files, rather than from within Visual Studio. So on all platforms, the workflow is similar to if you'd used plain old makefiles.
正如亚历克斯所说，它非常有效。惟一棘手的部分是要记住在cmake文件中做任何更改，而不是在Visual Studio中。因此，在所有平台上，工作流类似于使用普通的makefile。
But it's fairly easy to work with, and I've had no issues with cmake generating invalid files or anything like that, so I wouldn't worry too much.
但这很容易处理，我也没有遇到过cmake生成无效文件之类的问题，所以我不会太担心。
#5
6
CMake can generate really nice Visual Studio .projs/.slns, but there is always the problem with the need to modify the .cmake files rather than .proj/.sln. As it is now, we are dealing with it as follows:
CMake可以生成非常好的Visual Studio .projs/。但是，总是存在需要修改.cmake文件而不是.proj/.sln的问题。目前，我们的处理方式如下:
- All source files go to
/srcand files visible in Visual Studio are just "links" to them defined in.filter. - 所有源文件到/src，在Visual Studio中可见的文件只是在.filter中定义的“链接”。
- Programmer adds/deletes files remembering to work on the defined
/srcdirectory, not the default project's one. - 程序员添加/删除记住要处理已定义/src目录的文件，而不是默认项目的目录。
- When he's done, he run a script that "refreshes" the respective
.cmakefiles. - 完成之后，他运行一个脚本，“刷新”各自的.cmake文件。
- He checks if the code can be built in the recreated environment.
- 他检查代码是否可以在重新创建的环境中构建。
- He commits the code.
- 他提交的代码。
At first we were a little afraid of how it will turn out, but the workflow works really well and with nice diff visible before each commit, everyone can easily see if his changes were correctly mapped in .cmake files.
一开始我们有点担心它会变成什么样子，但是工作流工作得非常好，并且在每次提交之前都可以看到漂亮的diff，每个人都可以很容易地看到他的更改是否被正确地映射到.cmake文件中。
One more important thing to know about is the lack of support (afaik) for "Solution Configurations" in CMake. As it stands, you have to generate two directories with projects/solutions - one for each build type (debug, release, etc.). There is no direct support for more sophisticated features - in other words: switching between configurations won't give you what you might expect.
另一个需要了解的重要事情是CMake中的“解决方案配置”缺乏支持(afaik)。就目前的情况而言，您必须使用项目/解决方案生成两个目录——每个构建类型(调试、发布等)一个目录。没有对更复杂的特性的直接支持——换句话说:在配置之间切换不会得到您可能期望的结果。
#6
5
CMake produces Visual Studio Projects and Solutions seamlessly. You can even produce projects/solutions for different Visual Studio versions without making any changes to the CMake files.
CMake可以无缝地生成Visual Studio项目和解决方案。您甚至可以为不同的Visual Studio版本生成项目/解决方案，而无需对CMake文件进行任何更改。
Adding and removing source files is just a matter of modifying the CMakeLists.txt which has the list of source files and regenerating the projects/solutions. There is even a globbing function to find all the sources in a directory (though it should be used with caution).
添加和删除源文件只是修改CMakeLists的问题。txt，包含源文件列表并重新生成项目/解决方案。甚至还有一个globbing函数来查找目录中的所有源(尽管应该谨慎使用)。
The following link explains CMake and Visual Studio specific behavior very well.
下面的链接很好地解释了CMake和Visual Studio的特定行为。
CMake和Visual Studio
#7
0
I've started my own project, called syncProj. Documentation / download links from here:
我已经开始了我自己的项目，叫做syncProj。文件/下载链接:
https://docs.google.com/document/d/1C1YrbFUVpTBXajbtrC62aXru2om6dy5rClyknBj5zHU/edit# https://sourceforge.net/projects/syncproj/
https://docs.google.com/document/d/1C1YrbFUVpTBXajbtrC62aXru2om6dy5rClyknBj5zHU/edit https://sourceforge.net/projects/syncproj/
If you're planning to use Visual studio for development, and currently only C++ is supported.
如果您计划使用Visual studio进行开发，并且目前只支持c++。
Main advantage compared to other make systems is that you can actually debug your script, as it's C# based.
与其他make系统相比，主要的优势是您可以实际调试您的脚本，因为它是基于c#的。
If you're not familiar with syncProj, you can just convert your solution / project to .cs script, and continue further development from that point on.
如果您不熟悉syncProj，您可以将您的解决方案/项目转换为.cs脚本，并从那时开始继续进一步开发。
In cmake you will need to write everything from scratch.
在cmake中，您需要从头开始编写所有内容。
#8
0
Lots of great answers here but they might be superseded by this CMake support in Visual Studio (Oct 5 2016)
这里有很多很好的答案，但是它们可能会被Visual Studio的CMake支持所取代(2016年10月5日)
#1
53
CMake is actually pretty good for this. The key part was everyone on the Windows side has to remember to run CMake before loading in the solution, and everyone on our Mac side would have to remember to run it before make.
CMake其实很好。关键是Windows操作系统的每个人在载入解决方案之前都必须记住运行CMake，而Mac操作系统的每个人都必须记住在make之前运行它。
The hardest part was as a Windows developer making sure your structural changes were in the cmakelist.txt file and not in the solution or project files as those changes would probably get lost and even if not lost would not get transferred over to the Mac side who also needed them, and the Mac guys would need to remember not to modify the make file for the same reasons.
最困难的部分是作为Windows开发人员，确保您的结构更改在cmakelist中。txt文件,而不是在解决方案或项目文件,这些变化可能会迷路,即使不会丢失不会得到转移到Mac也需要他们,和Mac的家伙需要记住不要修改文件同样的理由。
It just requires a little thought and patience, but there will be mistakes at first. But if you are using continuous integration on both sides then these will get shook out early, and people will eventually get in the habit.
这只需要一点思考和耐心，但一开始就会出错。但是如果你在两边都使用连续的积分，那么这些就会被提前打乱，人们最终会养成这个习惯。
#2
37
Not sure if it's directly related to the question, but I was looking for an answer for how to generate *.sln from cmake projects I've discovered that one can use something like this:
不确定它是否与问题直接相关，但我正在寻找如何生成*的答案。来自cmake项目的sln，我发现人们可以使用这样的东西:
cmake -G "Visual Studio 10"
The example generates needed VS 2010 files from an input CMakeLists.txt file
该示例从输入CMakeLists生成所需的VS 2010文件。txt文件
#3
26
We moved our department's build chain to CMake, and we had a few internal roadbumps since other departments where using our project files and where accustomed to just importing them into their solutions. We also had some complaints about CMake not being fully integrated into the Visual Studio project/solution manager, so files had to be added manually to CMakeLists.txt; this was a major break in the workflow people were used to.
我们将我们部门的构建链转移到CMake，并且自从其他部门使用我们的项目文件并习惯于将它们导入到他们的解决方案之后，我们有了一些内部障碍。我们也有一些关于CMake没有完全集成到Visual Studio项目/解决方案管理器中的抱怨，因此文件必须手动添加到CMakeLists.txt中;这是人们习惯的工作流程中的一个重大突破。
But in general, it was a quite smooth transition. We're very happy since we don't have to deal with project files anymore.
但总的来说，这是一个相当平稳的过渡。我们很高兴，因为我们不用再处理项目文件了。
The concrete workflow for adding a new file to a project is really simple:
向项目添加新文件的具体工作流程非常简单:
- Create the file, make sure it is in the correct place.
- 创建文件，确保它在正确的位置。
- Add the file to CMakeLists.txt.
- 将该文件添加到CMakeLists.txt。
- Build.
- 构建。
CMake 2.6 automatically reruns itself if any CMakeLists.txt files have changed (and (semi-)automatically reloads the solution/projects).
CMake 2.6自动重新运行，如果有任何CMakeLists。txt文件已经更改(和(semi-)自动重新加载解决方案/项目)。
Remember that if you're doing out-of-source builds, you need to be careful not to create the source file in the build directory (since Visual Studio only knows about the build directory).
请记住，如果您正在进行源代码外的构建，您需要小心不要在构建目录中创建源文件(因为Visual Studio只知道构建目录)。
#4
10
As Alex says, it works very well. The only tricky part is to remember to make any changes in the cmake files, rather than from within Visual Studio. So on all platforms, the workflow is similar to if you'd used plain old makefiles.
正如亚历克斯所说，它非常有效。惟一棘手的部分是要记住在cmake文件中做任何更改，而不是在Visual Studio中。因此，在所有平台上，工作流类似于使用普通的makefile。
But it's fairly easy to work with, and I've had no issues with cmake generating invalid files or anything like that, so I wouldn't worry too much.
但这很容易处理，我也没有遇到过cmake生成无效文件之类的问题，所以我不会太担心。
#5
6
CMake can generate really nice Visual Studio .projs/.slns, but there is always the problem with the need to modify the .cmake files rather than .proj/.sln. As it is now, we are dealing with it as follows:
CMake可以生成非常好的Visual Studio .projs/。但是，总是存在需要修改.cmake文件而不是.proj/.sln的问题。目前，我们的处理方式如下:
- All source files go to
/srcand files visible in Visual Studio are just "links" to them defined in.filter. - 所有源文件到/src，在Visual Studio中可见的文件只是在.filter中定义的“链接”。
- Programmer adds/deletes files remembering to work on the defined
/srcdirectory, not the default project's one. - 程序员添加/删除记住要处理已定义/src目录的文件，而不是默认项目的目录。
- When he's done, he run a script that "refreshes" the respective
.cmakefiles. - 完成之后，他运行一个脚本，“刷新”各自的.cmake文件。
- He checks if the code can be built in the recreated environment.
- 他检查代码是否可以在重新创建的环境中构建。
- He commits the code.
- 他提交的代码。
At first we were a little afraid of how it will turn out, but the workflow works really well and with nice diff visible before each commit, everyone can easily see if his changes were correctly mapped in .cmake files.
一开始我们有点担心它会变成什么样子，但是工作流工作得非常好，并且在每次提交之前都可以看到漂亮的diff，每个人都可以很容易地看到他的更改是否被正确地映射到.cmake文件中。
One more important thing to know about is the lack of support (afaik) for "Solution Configurations" in CMake. As it stands, you have to generate two directories with projects/solutions - one for each build type (debug, release, etc.). There is no direct support for more sophisticated features - in other words: switching between configurations won't give you what you might expect.
另一个需要了解的重要事情是CMake中的“解决方案配置”缺乏支持(afaik)。就目前的情况而言，您必须使用项目/解决方案生成两个目录——每个构建类型(调试、发布等)一个目录。没有对更复杂的特性的直接支持——换句话说:在配置之间切换不会得到您可能期望的结果。
#6
5
CMake produces Visual Studio Projects and Solutions seamlessly. You can even produce projects/solutions for different Visual Studio versions without making any changes to the CMake files.
CMake可以无缝地生成Visual Studio项目和解决方案。您甚至可以为不同的Visual Studio版本生成项目/解决方案，而无需对CMake文件进行任何更改。
Adding and removing source files is just a matter of modifying the CMakeLists.txt which has the list of source files and regenerating the projects/solutions. There is even a globbing function to find all the sources in a directory (though it should be used with caution).
添加和删除源文件只是修改CMakeLists的问题。txt，包含源文件列表并重新生成项目/解决方案。甚至还有一个globbing函数来查找目录中的所有源(尽管应该谨慎使用)。
The following link explains CMake and Visual Studio specific behavior very well.
下面的链接很好地解释了CMake和Visual Studio的特定行为。
CMake和Visual Studio
#7
0
I've started my own project, called syncProj. Documentation / download links from here:
我已经开始了我自己的项目，叫做syncProj。文件/下载链接:
https://docs.google.com/document/d/1C1YrbFUVpTBXajbtrC62aXru2om6dy5rClyknBj5zHU/edit# https://sourceforge.net/projects/syncproj/
https://docs.google.com/document/d/1C1YrbFUVpTBXajbtrC62aXru2om6dy5rClyknBj5zHU/edit https://sourceforge.net/projects/syncproj/
If you're planning to use Visual studio for development, and currently only C++ is supported.
如果您计划使用Visual studio进行开发，并且目前只支持c++。
Main advantage compared to other make systems is that you can actually debug your script, as it's C# based.
与其他make系统相比，主要的优势是您可以实际调试您的脚本，因为它是基于c#的。
If you're not familiar with syncProj, you can just convert your solution / project to .cs script, and continue further development from that point on.
如果您不熟悉syncProj，您可以将您的解决方案/项目转换为.cs脚本，并从那时开始继续进一步开发。
In cmake you will need to write everything from scratch.
在cmake中，您需要从头开始编写所有内容。
#8
0
Lots of great answers here but they might be superseded by this CMake support in Visual Studio (Oct 5 2016)
这里有很多很好的答案，但是它们可能会被Visual Studio的CMake支持所取代(2016年10月5日)