将现有的C ++源代码导入Visual Studio [英] Import Existing C++ Source Code into Visual Studio

问题描述

我试图将现有的c ++应用程序的源代码导入visual studio，以利用一些特定的MS工具。但是，在在线搜索和使用visual studio之后，我似乎找不到一个简单的方法将现有的c ++源代码导入到可视工作室，并保持其结构完整。

I am trying to import an existing c++ application's source into visual studio to take advantage of some specific MS tools. However, after searching online and playing with visual studio, I cannot seem to find an easy way to import existing c++ source code into visual studio and keep it structurally intact.

导入容量我找到了平整的目录，并把它们都放到一个项目。

The import capacity I did find flattens out the directories and puts them all into one project. Am I missing something?

（这是所有非托管C ++，并且包含win / unix的特定版本）

(This is all unmanaged C++, and contains specific builds for win/unix)

推荐答案

我不知道在给定的约束下的任何一般解决方案 - 特别是要从源代码树创建许多项目。

I am not aware of any general solution under the constraints given - specifically having to create many projects from a source tree.

我看到的最好的选择是实际上通过一些脚本创建项目文件。

The best option I see is actually creating the project files by some script.

• 手动创建单个项目（创建空项目，然后添加文件），


• 配置


• 使用作为要创建的项目文件的骨架创建的.vcproj

一个非常简单的方法将文件列表，项目名称等与奇怪的令牌，并填写他们的发电机。如果你想成为好人，你当然可以使用一些XML处理库。

A very simple method would file list, project name etc. with "strange tokens", and fill them in with your generator. If you want to be the good guy, you can of course use some XML handling library.

：我们实际上不再将.vcproj和.sln存储在存储库（git）中，而是一个从源代码树重新生成它们的python脚本，以及VS 2008的属性表模板无论他们叫什么）。这有助于进行大量的调整。

Our experience: We actually don't store the .vcproj and .sln in the repository (git) anymore, but a python script that re-genrates them from the source tree, together with VS 2008 "property sheet templates" (or whatever they are called). This helps a lot making general adjustments.

项目生成脚本包含有关所有项目特色的信息（例如，它们使用MFC / ATL，它将创建DLL或EXE，要排除的文件）。

The project generation script contains information about all the projects specialties (e.g. do they use MFC/ATL, will it create DLL or an EXE, files to exclude).

此外，此脚本还包含依赖项，它提供实际的构建脚本。

In addition, this script also contains dependencies, which feeds the actual build script.

这样工作得很好，问题很小：python在编译系统中需要，不要忘记重新生成项目文件，我不得不学习一些python进行调整一些项目。

This works quite well, the problems are minor: python requried in build systems, not forgetting to re-gen the project files, me having to learn some python to make adjustments to some projects.

@Michael Burrpython脚本和支持的模板可能需要？

@Michael Burr "How complex are the python scripts and whatever supporting 'templates' you might need?"

我真的不能告诉，因为我把任务交给了另一个开发者（选择python）。最初的任务是提供一个构建脚本，因为VS2008解决方案构建不足以满足我们的需要，而旧的批处理文件不支持并行化。 .vcproj 后添加。我理解他的脚本从头开始生成.vcproj和.sln文件，但从单独的属性表中提取所有设置。

I honestly can't tell, since I gave the task to another dev (who picked python). The original task was to provide a build script, as the VS2008 solution build was not good enough for our needs, and the old batch file didn't support parallelization. .vcproj generation was added later. As I understand his script generates the .vcproj and .sln files from scratch, but pulls in all the settings from separate property sheets.

优点：

• 新配置即时。一些项目已经有六个配置，并且计划unicode支持意味着考虑一倍他们。一些笨拙的工具仍然构建为MBCS，所以一些libs现在有8个配置。配置从手是一个痛苦，现在它只是不打扰我了。

• Adding new configurations on the fly. Some of the projects already had six configurations, and planning for unicode support meant considering doubling them for a while. Some awkward tools still build as MBCS, so some libs do have 8 configs now. Configuring that from hand is a pain, now it just doesn't bother me anymore.

全局变更，例如移动相对项目路径，临时文件和最终二进制文件夹，直到我们找到一个我们对

Global changes, e.g. moving around relative project paths, the folder for temp files and for final binaries until we found a solution we were happy with

构建稳定性感到满意的解决方案。合并VC6项目文件是出于各种原因的一个显着的错误源，并且VC9项目文件看起来不太好。现在事情看起来更孤立：在属性表中编译/链接设置，脚本中的文件处理。此外，脚本主要列出了默认中的变体，比项目文件更容易阅读。

Build Stability. Merging VC6 project files was a notable source of errors for various reasons, and VC9 project files didn't look better. Now things seem isolated better: compile/link settings in the property sheets, file handling in the script. Also, the script mostly lists variations from our default, ending up easier to read than a project file.

通常：当你的项目已经设置好，它们相当稳定，你没有真正的问题，我没有看到一个很大的好处。但是，当移动到未知（对我们来说：主要是VC6 - > VC9和Unicode构建），灵活性大大降低了实验的风险。

Generally: I don't see a big benefit when your projects are already set up, they are rather stable, and you don't have real issues. However, when moving into the unknown (for us: mostly VC6 -> VC9 and Unicode builds), the flexibility reduced the risk of experiments greatly.

这篇关于将现有的C ++源代码导入Visual Studio的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！