c++ - 管理 C++ 项目 - 文件布局、依赖关系和版本控制

Question

我最近开始了一个新的 C++ 项目，我打算及时将其跨平台。我之前对 C++ 项目没有太多经验，所以首先困扰我的是默认的 Visual Studio 文件布局设置。我试着在网上阅读关于这个主题的信息，但信息似乎很少而且相互矛盾，所以我开始做一些像这样简单的事情:

build
  vc2010  // Visual C++ solution/project files
lib 
  include // Header files for third-party libs
  // All library binaries here (like .lib, .dll or .so)
src
  // My own code (including headers)
temp
  // I use this as intermediate file output directory (for Visual C++)

然后 Visual C++ 项目被配置为在根项目目录(调试/发布版本)中输出最终的 .exe，这样我也可以将自己的特定数据放在那里(如 data/ 目录)。请注意，我打算在源版本控制存储库(不包括某些类型，如 .exe)下管理我的项目，我不是在这里编写库。所以我的问题是:

您的项目结构是否有任何实际标准？或者它们是特定于平台和用户的？

您如何处理库依赖性？您是只放置预编译的二进制文件(如在我的设置中)还是使用完整的库源代码并设置您的项目构建过程以将它们包含在过程中。将二进制文件置于版本控制之下(如本例中的 .lib/.dll)是个好主意吗？

Answer 1

请记住当您切换到另一个平台上的不同构建系统时会发生什么。

它不知道如何处理解决方案/项目文件，它们是特定于 Visual Studio 的。所以你如何构建它并不重要。无论如何你都会重新做。

与 temp 目录一样，中间文件是特定于构建系统的，它们不一定必须在自己的树中关闭。您可能希望坚持使用每个平台的默认设置，无论它是什么。

对于第三方依赖项，您可能会发现它们已经安装(或可以安装)在您要移植到的系统上，在这种情况下您可能会很乐意使用已安装的版本，或者您可能依赖于一个非常具体的版本。无论哪种方式，预编译的二进制文件在另一个系统上都是无用的。

因此，如果您想随身携带第三方依赖项并在任何地方编译它们，那么您需要像对待自己的源一样对待它们，但在另一个根目录中。版本控制源而不是二进制文件。如果你打算使用为目标平台预编译的任何可用的东西，你可能会发现你必须在不同的平台上做些不同的事情，但基本上你要么把它们贴在某个地方，要么找到它们已经安装的地方，并将该“某处”放在您的包含路径(对于头文件)和您的链接器路径(对于二进制文件)中。

为了安全起见，您可能希望对二进制文件进行版本控制，或者您可以只记下您正在使用的版本，并使用备份而不是版本控制来防止它们无法下载 future 。

如果您想从一开始就针对可移植性进行设计，那么同时为两个不同的系统进行设置可能是个好主意。您可以在不离开 Windows 的情况下执行此操作 - 例如，尝试安装 Code::Blocks 并使用 MinGW 进行构建，以及您已经使用 Visual Studio 进行的操作。

另请注意，您自然会在 Windows 上使用的许多库在其他平台上根本不可用。如果您已经基于 Windows API 编写了 GUI 应用程序，然后您想要将其移植到 OSX，那么构建系统将是您最不担心的事情。