11

最近、いくつかのオープン ソース プロジェクトを Subversion から git に移行し、その後 Github に移行しました。Github は、多くの機能を提供するという点で優れていました。私が特に気に入っていることの 1 つは、タグをzipまたは.tar.gzファイルとしてダウンロードできることです。

残念ながら、Github は最近ダウンロードを中止しました。タグをダウンロードできるため、これは問題になりません。ただし、これまではMakefile、configureスクリプトやその他の autoconf で生成されたファイルをレポに配置していませんでした。これは、人々がマージすると多くの競合が発生するためです。

これを処理する適切な方法は何ですか？

  • タグを直接ダウンロードできるように、autoconf と automake で生成されたファイルをリポジトリに配置する必要がありますか?
  • それともbootstrap.shファイルが必要で、人々はそれを実行するように言われますか?
  • それとも、make distそれをレポに入れるだけですか？

ありがとう

4

3 に答える 3

19

の出力make distを GitHub Releases 経由で公開する

Autoconf および Automake で生成されたファイルをリポジトリに配置するという最初のオプションは、お勧めできません。生成されたファイルをソース管理に保存することは、ほとんど有益ではありません。この場合、特にすべての貢献者が同じバージョンの Autotools を使用しているわけではない場合、不必要で競合する可能性のある多くのコミットで履歴が汚染されます。3 番目のオプション (の出力をチェックインする) はmake dist、最初のオプションとまったく同じ理由で悪い考えです。

2 番目のオプション (Autoconf と Automake を呼び出してconfigureスクリプトを生成する「ブートストラップ」スクリプトを追加する) も悪い考えです。これは、Autotools が利用できないシステムを含め、システム間でソースを移植可能にするという Autotools の目的全体を無効にします! (誰かがルート アクセス権を持たず、GNU ビルド システムがインストールされていないマシンでソフトウェアをビルドしてインストールしようとした場合にどうなるか考えてみてください。ブートストラップ スクリプトは役に立ちません。最初に、Autotools と、場合によってはそのすべての依存関係をローカルにインストールする必要があります。)

Autotools を使用するコードをリリースする適切な方法は、 を使用して tarball を作成しmake dist(またはmake distcheck、これによりテストも実行され、他のサニティ チェックも実行されるため、より良い方法で)、この tarball をソース リポジトリ以外の場所に公開することです。

2013 年 4 月からの最初の質問では、GitHub がダウンロード ページを廃止したと述べています。ただし、2013 年 7 月に、GitHub は「リリース」機能を追加しました。この機能は、ソース タグを事前にパッケージ化するだけでなく、各リリースに任意のファイルを添付することもできます。したがって、GitHub では、リリース ページでmake disttarballを公開する必要があります(できれば、それらの分離された GnuPG 署名も公開する必要があります)。

基本的な手順

  1. リリースの準備ができたら、タグを付けて、そのタグを GitHub にプッシュします。 $ git tag 1.0 # Also use -s if desired $ git push --tags
  2. Makefile を使用して tarball を生成します。 $ make dist # Alternatively, 'make distcheck'
  3. プロジェクトの GitHub ページにアクセスし、「リリース」リンクをたどります。 リリース リンクの場所を示す GitHub プロジェクトのスクリーンショット
  4. プロジェクトのリリース ページが表示されます。初めてアクセスすると、タグのリストと、ソース ツリーから自動的に生成された tarball が 表示されGitHub リリース ページ ます。[Draft a new release] ボタンをクリックします。
  5. 次に、リリースに関連付けられた Git タグと、オプションのタイトルと説明を入力するフォームが表示されます。この下には、「ここにドロップするか選択してバイナリを添付する」というラベルの付いたファイル セレクターもあります。これを使用して、手順 2 で作成した tarball をアップロードします (また、その分離された GnuPG 署名も含まれる場合があります)。 GitHub リリースの下書き 完了したら、「リリースを公開」ボタンを押します。
  6. プロジェクトのリリース ページに、添付ファイルの目立つダウンロード リンクを含むリリースが表示されます。 完成した GitHub リリース ページ

GitHub リリースを使用したくない場合は、前の回答で指摘したように、自分の Web サイトや FTP サイトなど、別の場所に tarball をアップロードする必要があります。プロジェクトからこのリポジトリへのリンクを追加してREADME.md、ユーザーが見つけられるようにします。

于 2016-12-28T10:41:55.680 に答える
4

2 番目の方が優れています。レポのすべてのユーザーができるだけ早く稼働し、プログラムをビルドするために必要なものを再生成する必要があります。

Git は ( Nexus のようなアーティファクト リポジトリとは対照的に)テキストのバージョン管理に非常に適しているため、最終的なバイナリを生成する方法を提供することが最善の方法です。

于 2013-04-01T14:48:32.007 に答える
-1

リリースをカットしたら、結果をmake distcheckプロジェクトのダウンロード ページにアップロードします。これは、tarball をビルドし、インストール、アンインストール、テストおよびその他のサニティ チェックに合格することを検証する makefile ターゲットです。Github の頭が間違っていることは言い訳にはなりません。リポジトリに次のようなツリーを作成します。

/
/source
/source/configure.ac
/source/Makefile.am
/source/...
/releases
/releases/foo-0.1.tar.gz
/releases/...

開発者の場合、ソース管理でファイルを生成するべきではありません。多くの最新の自動ツール化プロジェクトは、 の呼び出しをうまくブートストラップしますautoreconf -i。

于 2013-04-02T00:11:04.810 に答える