10

我即将根据 GPL 将我一直在从事的项目上传到 Sourceforge 上，并希望获得一些关于如何以易于理解和任何可能查看的开发人员使用的方式组织代码的建议它与 git 以及 Sourceforge 呈现事物的方式配合得很好。

我的项目是一个跨平台的 C++ 应用程序，包括以下内容：

  • 执行实际工作的库部分
  • 一个单独的 GUI 部分，它使用库部分
  • 开源库，编译库需要包含路径
  • 已修改的开源库，因此在某种意义上也是该项目的直接部分
  • 所有库的编译输出

组织这个的最佳方式是什么？

在自己处理它时，从项目根目录我有这样的：
/LibPortion
/GuiPortion
/libs/open source libraries
/libs/modified open source libraries
/libs/compiled/ 保存已编译的库，包括在为 Windows 编译时不是来自开源库的，例如 Cygwin 库文件

这是一种合理的组织方式吗？这符合惯例和期望吗？

签入我的项目时，签入开源库以及项目的一部分是否有意义？我认为这样做是有意义的，因为这可以最大限度地减少为新开发人员设置和运行项目的摩擦。当然，我至少应该检查修改后的开源库。

此外，在已编译库下的存储库中包含什么意义？我认为最好告诉 git 忽略该目录并将其留空，因为它的内容在每个构建目标上都会有所不同，因为我的项目是跨平台的。

但是，对于不想自己构建和/或下载所有库以提供为主要平台预编译的库的人来说，这似乎也非常好。分享这些最聪明的方法是什么？我正在查看 Sourceforge，如果不是作为我的 git 存储库的一部分，我应该如何分享这些对我来说并不明显。

4

4 回答 4

5 

/
|- 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.

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

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

于 2010-07-26T20:23:23.960 回答
3

如果我是你，我会首先将你自己的代码和第三方库之间的项目分开。以下树可以工作：

/
|- GUI
|- lib
|- third parties
    |- compiled targets
    |- "your first library"
    |- "another library"
    |- ...

您不应该在您的存储库 imho 上托管已编译的库。让开发人员在他们自己的计算机上编译它们更加灵活，但是如果你想要一个可交付的 tarball，它应该包含预编译的库。

于 2010-07-26T17:31:28.583 回答
3

一般来说，将您的工作与第三方的工作分开。在最基本的层面上，您的根文件夹可能如下所示：

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

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

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

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

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

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

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

于 2010-07-26T20:59:06.010 回答
0

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

vlc 项目页面可以作为一个很好的参考

于 2012-10-05T13:37:45.147 回答