Question

Answer 1


/
|- bin - Compiled binaries go here (not submitted to source-control)
|- build - buildscripts, tools used to build your code.
|- lib - Compiled libraries go here (not submitted to source-control)
|- local - (not submitted to source control)
   |- obj - Compiled object-files (not submitted to source-control)
   |- msvc - Autogenerated solution files for visual studio (not submitted to source control) (if applicable)
   |- scripts - Autogenerated script files (if applicable)
|- units
   |- libportion
      |- include - external headers for other units to see
      |- src
   |- guiportion
      |- include
      |- src
|- external
   |- externallib1
      |- include
      |- src

build - simplified build-script calling the correct convention to your buildscripts.
README - text-file explaining your software and the layout of your source.

这是我最近一直在使用的组织，所有人都非常喜欢这个组织。它还可以轻松地将库彼此分开，并且可以轻松地在库中提供内部头文件和外部头文件。

编辑：添加了“本地”目录。

Answer 2

一般而言，将您的工作与第三方的工作分开。在最基本的级别上，您的根文件夹可能如下所示：

|- GUI
|- Library
|- Third-party
    |- lib
    |- source

我将“第三方”文件夹分成两个子文件夹，以实现许可证合规性和易用性。您如何分发第三方库将完全取决于他们的许可证。设置你的makefile，以便编译的库将落在third-party\lib文件夹中（你也可以放置任何预编译的库）。这样，用户可以下载预编译的lib并忽略source文件夹或下载源代码并忽略lib文件夹，具体取决于他们是否要重新构建第三方库

如果您需要以二进制和源代码形式分发修改后的版本，那么您需要在源代码库中托管修改后的版本（提供预编译的lib是您的选择）。

如果您正在使用未修改的库并且您正在使用Subversion存储库（或类似），则可以使用externals属性将存储库链接到第三方库的存储库，以便在用户获取副本时你的源代码，它从它自己的repo抓取lib的源代码。这样，您就不必保留库源的本地镜像。根据第三方lib在其repo中可用的内容，您也可以使用外部链接链接到第三方库的预编译版本。这不仅会减少您在repo中托管的代码量，而且还会更清楚地表明特定的第三方lib尚未修改。

使用未修改的库时，根本不在源树中包含源或二进制文件会更好。只需在文档中记下您的项目依赖于库X（如果它很重要，请指定版本）并提供指向该库的项目主页/ Sourceforge页面/存储库的链接。让开发人员决定是否要编译库，下载预编译版本，或者可能使用已安装的版本。这意味着您也不能假定库或其标题将存在于相对于源代码的特定目录中;相反，您必须信任用户安装编译器可以找到它们的库。您的代码将简单地假设它们位于编译器的搜索路径中。

您的修改后的库也可能被实现，使得externals属性将导致从第三方仓库中检索未修改的源，并且您的构建系统可以应用包含您的修改的修补程序。这样，您就不会在技术上分发修改后的代码，这可能意味着您必须遵守的许可条款要少几个。

通常，我不建议在源存储库中分发库的预编译版本。使用Sourceforge，您可以为主要平台预编译您的库（或任何其他“最终产品”）并将其作为下载提供。

Answer 3

恕我直言，看看各种开源项目的组织可能有所帮助。

vlc project page可以是一个很好的参考

4 个答案: