10

私が取り組んでいるプロジェクトを GPL の下で Sourceforge にアップロードしようとしています。それはgitとうまく機能し、Sourceforgeが物事を提示する方法です。

私のプロジェクトはクロスプラットフォームの C++ アプリケーションであり、次のもので構成されています。

  • 実際の作業を行うライブラリ部分
  • ライブラリ部分を使用する別の GUI 部分
  • ライブラリのコンパイルにインクルード パスが必要なオープン ソース ライブラリ
  • 変更されたオープン ソース ライブラリは、ある意味でこのプロジェクトの直接の一部でもあります。
  • すべてのライブラリのコンパイル済み出力

これを整理する最良の方法は何ですか?

自分で作業している間、プロジェクトルートから次のようにしています:
/LibPortion
/GuiPortion
/libs/open source libraries
/libs/modified open source libraries
/libs/compiled/ コンパイル済みライブラリを保持します。 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

ライセンスの遵守と使いやすさのために、「サードパーティ」フォルダーを 2 つのサブフォルダーに分けました。サードパーティのライブラリをどのように正確に配布するかは、そのライセンスに完全に依存します。コンパイルされたライブラリがフォルダーに配置されるようにメイクファイルを設定しthird-party\libます (このフォルダーには、コンパイル済みのライブラリも配置されます)。そうすれば、サードパーティのライブラリを再構築するかどうかに応じて、ユーザーはコンパイル済みのライブラリをダウンロードしてsourceフォルダーを無視するか、ソース コードをダウンロードしてフォルダーを無視することができます。lib

変更したバージョンをバイナリおよびソース コード形式で配布する必要がある場合は、変更したバージョンをソース リポジトリでホストする必要があります (コンパイル済みのライブラリを選択する場合)。

変更されていないライブラリを使用していて、Subversion リポジトリ (または類似のもの) を使用している場合は、externalsプロパティを使用してリポジトリをサードパーティ ライブラリのリポジトリにリンクし、ユーザーがソース コードのコピーを取得したときにそれを取得できるようにすることができます。独自のレポからのライブラリのソース。そうすれば、ライブラリ ソースのローカル ミラーを保持する必要がなくなります。サードパーティのライブラリがリポジトリで利用できるものに応じて、外部を使用してサードパーティのライブラリのコンパイル済みバージョンにリンクすることもできます。これにより、リポジトリでホストする必要があるコードの量が減るだけでなく、特定のサードパーティ ライブラリが変更されていないことがより明確に示されます。

変更されていないライブラリを使用する場合は、ソース ツリーにソースまたはバイナリをまったく含めない方がよいでしょう。プロジェクトがライブラリ X に依存していることをドキュメントに書き留め (重要な場合はバージョンも指定)、そのライブラリのプロジェクト ホームページ/Sourceforge ページ/リポジトリへのリンクを提供します。ライブラリをコンパイルするか、事前にコンパイルされたバージョンをダウンロードするか、あるいは既にインストールされているバージョンを使用するかは、開発者に決定してもらいます。これは、ライブラリまたはそのヘッダーが、ソース コードに関連する特定のディレクトリに存在すると想定できないことも意味します。代わりに、ユーザーを信頼して、コンパイラがライブラリを見つけられる場所にライブラリをインストールする必要があります。コードは、それらがコンパイラの検索パスにあると単純に想定します。

また、externals プロパティによって変更されていないソースがサードパーティ リポジトリから取得され、ビルド システムが変更を含むパッチを適用できるように、変更されたライブラリが実装される可能性もあります。この方法では、技術的に変更されたコードを配布することはありません。つまり、従わなければならないライセンス条項がいくつか少なくなる可能性があります。

通常、ソース リポジトリ内でライブラリのコンパイル済みバージョンを配布することはお勧めしません。Sourceforge を使用すると、主要なプラットフォーム用にライブラリ (またはその他の「最終製品」) を事前にコンパイルし、ダウンロードとして提供できます。

于 2010-07-26T20:59:06.010 に答える
0

さまざまなオープンソース プロジェクトの組織を見ている私見が役立つかもしれません。

vlc プロジェクト ページが参考になります

于 2012-10-05T13:37:45.147 に答える