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/ dir）。请注意，我打算在源版本控制存储库（不包括某些类型，如.exe）下管理我的项目，我不在这里编写库。所以我的问题是：

是否有任何事实上的标准来构建您的项目？或者它们是平台和用户特定的吗？

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

Answer 1

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

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

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

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

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

您可能希望版本控制二进制文件是安全的，或者您可以只记下您正在使用的版本，并使用备份而不是版本控制作为您的保险，以防止它们无法下载将来

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

另外要注意，很多在Windows上自然使用的库，在其他平台上都不可用。如果您编写了基于Windows API的GUI应用程序，那么构建系统将是您最不担心的，然后您希望将其移植到OSX。

Answer 2

如果您想使用Visual Studio（VC ++ 可以在没有它的情况下使用），那么您应该注意一些事项。您可以更改其获取文件的位置以及放置文件的位置，因此您不会将其绑定到默认结构。但是，它的一些子工具在使用具有相同名称的不同源文件（显然在不同目录中）时会遇到麻烦，所以应该避免这种情况。

此外，您有标准的Windows限制，大写在文件名中并不重要，因此您必须阻止Unix人员使用其Unix文件系统的该功能。

Answer 3

我知道这个帖子已经超过两年了，但它仍会出现在谷歌搜索中，所以我会告诉我自己对这个混乱的看法......

首先，你必须明确决定是否要进行跨平台开发......我不只是指多个操作系统，而是多个编译器，ide（？）和标准库。即使在Unix中，Linux和BSD之间存在重复关系，有人说这只是许可问题，但代码似乎正朝着不同的方向发展。

所以，要做的第一件事就是解决构建你的东西的问题，你可能只使用一个生成其他所有内容的文件（比如CMake，bakefile或其他试图比make更好的文件），或者你可以有一个构建目录，其中包含许多单独维护的构建文件，当没有太多不同的平台时，秒就可以正常工作（大多数情况下，你会有一个make的组合（或其中一个变体） tup）和gcc或clang或[在这里插入其他基于unix的编译器]，你将拥有borland，visual studio等等。

其次，如果您正在编写库，则可能需要将外部标头和其余代码分离到不同的目录中，这样可以简化构建库和安装标头和已编译二进制文件的任务（二进制文件）这种情况总是被编译，所以你可能会删除在二进制文件之前编译的。）

第三，总是有文档，这通常是工程手册，几乎每本技术手册，有时被开发人员遗忘，但这很重要，因为你的用户不会通过水晶球理解你的代码，你可能想要使用像doxygen（用于C ++）和docbook / markdown / ......之类的东西（我实际上是想弄清楚最后一部分，非技术文档），一个很酷的目标是拥有存储库中的文档，当您更新文档时，构建脚本会重新生成网站，并且通过使用git子模块之类的东西，每当有人从您的代码存储库中检出或更新它们的代码时，它们也会检查最多迄今为止的文件。（这基本上就是maven doxia试图为java做的事情，即使工作流程很糟糕）

所以最后你可能会以一个src文件夹，一个include文件夹（如果你有公共头文件），一个doc文件夹（包含你的文档），一个build文件夹（如果有多个构建脚本）和一个资源结束或资产文件夹（如果您有相关文件，如图像，翻译文本，xml文件，文件数据库（如sqlite）等）。如果你像我这样的懒惰类型意味着要完成很多工作，那么为了设置项目（使其可构建，可测试并能够生成文档）。

关于源外构建，取决于你，虽然有些工具会激励它（想到CMake），但是记得设置你的存储库，这样就不会出现任何垃圾文件，无论是偶然还是因为某些笨拙的开发者将他们放在那里。如果必须，只需将所有构建文件（例如VC ++中的构建文件）放入特定于该构建文件的目录（如vcbuild）中，并编写一个安装脚本来放置二进制文件和所需文件，其中用户需要它们，您只需配置源控制系统，忽略这些目录及其下的所有内容。

Answer 4

请记住，无论您在Visual Studio中进行开发时如何努力使其变得便携，它都会在您第一次尝试在任何其他平台上构建/运行时中断。

如果您希望项目是跨平台的，那么我建议从一开始就至少从两个平台开始（例如，Windows和Linux），并经常确保它在两者上构建/运行。我还建议从Visual Studio以外的东西开始...不是因为VS很糟糕......它不适合建立跨平台项目。我喜欢CMake和非源代码构建。

如果应用程序具有GUI，请使用便携式GUI库，如wxWidgets，QT等。

坚持使用已知可移植的内容...... boost，libxml2，ODBC等。

管理C ++项目 - 文件布局，依赖项和版本控制

4 个答案: