假设您有一些来自 unix 世界的源代码。这个源代码由几个文件组成，这些文件将创建一个库和许多小的 .c 文件（比如 20 个左右），这些文件被编译成命令行工具，每个都有自己的 main() 函数，将使用该库。
在 unixy 系统上，您可以使用 makefile 轻松完成此操作，但对 windows / Visual Studio 世界最天真的转换涉及为每个工具创建一个单独的项目，虽然它有效，但设置和设置工作量很大在文件系统和项目/解决方案级别同步和更难导航。我曾考虑过使用不同的配置，其中除了一个 .c 文件之外的所有文件都被排除在构建之外，但这会使同时构建所有工具变得不可能。
有没有一种从单个“事物”（项目、msbuild 文件等）构建所有工具的好方法？
我真的对使用 cygwin 的 gcc/mingw 或 NAnt 不感兴趣。我想尽可能地坚持使用标准的 Windows 工具链。
【问题讨论】：
标签： c windows visual-studio msbuild
您没有必须使用 Visual Studio 来编译代码。您可以制作自己的批处理文件或 Powershell 脚本，只需在源代码上调用编译器，就像 makefile 一样。
【讨论】：
所以我一直在研究这个问题，但解决方案都有很多不足之处。
你可以...
手工创建很多小项目。
使用 MSBuild 并处理其陡峭的学习曲线。
使用无法与 Visual Studio 很好集成的构建工具，例如 GNU make。
您甚至无法像使用 .NET 项目那样制作项目模板！好吧，如果您想浏览文档，我想您可以制作一个向导。就个人而言，我决定采用“许多小项目”的解决方案并处理它。事实证明，它可能没有我想象的那么可怕，尽管它仍然很糟糕。这是我在 Visual Studio 2008 中所做的：
创建您的第一个 Win32 命令行工具项目，为所有平台设置所有设置，并确保它在所有情况下都能正常工作。这将成为您的“模板”，因此您不想在复制 20 份后对其进行编辑。
（可选）我在 Visual Studio 项目文件中设置了路径，以便在项目目录中构建所有内容，然后我有一个构建后步骤复制我需要的 dll/exe/pdb 文件$(SolutionDir)$(OutDir)。这样你就可以跳到一个目录来测试你所有的工具和/或将它们打包成一个二进制发行版。 VS2008 似乎很疯狂，并且到处都放置输出文件夹，Win32 和 x64 输出的默认位置不同。花几分钟时间来确保所有平台的一致性将在以后获得回报。
清理您的模板。摆脱任何用户设置文件和编译器输出。
根据需要多次复制和粘贴您的项目。每个工具一个项目。
将每个复制的项目文件夹和项目文件重命名为新的工具名称。在 Notepad++ 等文本编辑器中打开项目文件。如果您有一个简单的 1 文件项目，则需要在文件开头的两个位置更改项目名称，并在文件末尾更改源代码文件名。您应该不需要触摸中间的配置内容。
您还需要更改项目的 GUID。弹出打开 guidgen.exe（在 SDK bin 目录中）并使用最后一个单选按钮设置。将新的 GUID 复制并粘贴到顶部的每个项目文件中。如果您有依赖项，则在靠近源代码的文件底部会有一个或多个 GUID。不要更改它们，因为它们是依赖项中的 GUID，并且必须匹配！
进入 Visual Studio，打开您的主解决方案并添加您的工具项目。
进入配置管理器并确保所有支持平台的一切都正确，然后测试您的构建。
它并不漂亮，但它可以工作，而且非常值得花时间从 GUI 控制您的构建。希望VS2010会在这方面做得更好，但我并不太抱有希望。看起来 MS 现在对 .NET 社区的喜爱比对 C/C++ 社区的喜爱要多得多。
【讨论】：
如果您有一个 makefile，您可以在 Visual Studio 中使用一个“makefile”项目（它的名称有误 - 它只是允许您指定自定义构建/调试命令），并使用它来调用 GNU make。
您需要更改 makefile 以使用 VC++ 命令行工具，而不是使用 cc 或 gcc 或其他任何工具，但这些通常由 makefile 顶部的宏指定。
如果 makefile 使用其他 Unix 特定命令（例如 rm），您可能需要进行修改，或创建 Bath 文件以将命令映射到 Windows 等效命令。另一种选择是从GNUWin32 安装任何必要的工具以使其工作。
如果构建非常复杂或涉及配置脚本，那么您将面临更艰巨的任务。您可以使用 MSYS/MinGW 从配置脚本生成 makefile，然后按上述方式对其进行修改以使其与 VC++ 一起使用。
但是，Makefile 项目不会像 Visual Studio 那样紧密集成。所有的构建管理都取决于您和 makefile。
【讨论】：
如果您真的在使用 Visual Studio，我建议为每个工具创建一个项目，并将这些项目添加到单个解决方案中。在 Visual Studio 中，一次构建完整的解决方案很容易，而且 MSBuild 也知道如何构建 .sln 文件。
msbuild myslnfile.sln
甚至：
msbuild
... 将构建您的解决方案。
【讨论】：