我即将在Sourceforge上开源一个C++项目.我可以获得有关代码组织的一些提示吗？

Question

我即将在GPL下上传一个我一直在使用Sourceforge的项目,并希望得到一些关于如何以易于理解和使用的方式组织代码的建议.它,适用于git,以及Sourceforge呈现的方式.

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

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

组织这个的最好方法是什么？

在我自己工作的时候,从项目根目录开始我就像这样:
/ LibPortion
/ GuiPortion
/ libs /开源库
/ libs /修改的开源库
/ libs/compiled /来保存已编译的库,包括编译Windows时的一些这不是来自开源库,例如Cygwin库文件

这是组织事物的明智方式吗？这符合惯例和期望吗？

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

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

然而,对于那些不想为构建和/或下载所有库本身来提供为主要平台预编译的库而烦恼的人来说,这似乎也很不错.分享这些最聪明的方法是什么？我正在寻找Sourceforge,对我来说,如果不是作为我的git存储库的一部分,我应该如何分享这些内容并不是很明显.

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文件夹中（您也可以在该文件夹中放置任何预编译的库）。这样，用户可以下载预编译的库并忽略该source文件夹，或者下载源代码并忽略该lib文件夹，具体取决于他们是否想要重新构建第三方库。

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

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

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

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

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