3

AM_MAINTAINER_MODE批判されており、主な反対意見は、メタファイルへの依存関係が検出されない場合、誤ったビルドにつながることだと思います。また、生成されたファイルはバージョン管理システムに属していないという議論もよくあります（私はその立場に同意します）。私は現在configure、vcsに属していない場合、configure.acおよびMakefile.amtarballに属していないことを信じています。そのために、Makefile.inから特定のターゲットを削除する簡単なスクリプトを作成し、次のターゲットをトップレベルのMakefile.amに追加しました。

dist-hook:
    @rm $(distdir)/configure.ac
    @rm $(distdir)/aclocal.m4
    @find $(distdir) -name Makefile.am -exec rm {} \;
    @find $(distdir) -name Makefile.in -exec $(top_srcdir)/clean-Makefile {} \;

AM_MAINTAINER_MODEこのソリューションは、変更するメタファイルがないために発生する問題のある問題を回避します。

autoconfの最大の失敗の1つは、autoconfを使用して構築されたすべてのプロジェクトがautoconfに依存しているという誤解であり（これはautoconfの失敗ではなく、マーケティング/教育の失敗です）、この誤解は主にメタファイルを含むtarball。

質問：autotoolメタファイルを含まないtarballを作成するという望ましい目標を達成するためのより良い方法はありますか？（その目標が単に「おそらく望ましくない」か「本当に悪」であるかという問題は、このフォーラムにはあまりにも開かれています！）

4

1 に答える 1

1

これを行う方法があるかもしれませんが、Automakeはそれがあったとしてもそれをサポートしません。

Automakeの主な目標は、Makefileに関するGNUコーディング標準を実装することです。そして、ユーザーがハッキングする一次資料を与えられるべきであるというのはGNUの信条です-これはGPLの要件です。

ソースではなく派生ファイルを出荷することは、この考えに反します。

ここでのあなたの理論は誤った方向に進んでいると思います。ユーザーはソースを持つことで恩恵を受けます。たとえば、構成またはビルドスクリプトをハックする必要があるのはかなり一般的です。これはソースコードを使用するとはるかに簡単です。

于 2013-11-05T02:21:14.860 に答える