このコードスニペットは次のとおりです。
AM_MAINTAINER_MODE
if test "x$enable_maintainer_mode" = xyes; then
AC_PATH_PROG(PERL,perl)
if test -z "$PERL"; then
AC_MSG_ERROR([perl not found])
fi
fi
# This should be checked before AC_PROG_CC
if test "x$CFLAGS" = x; then
default_CFLAGS=yes
fi
if test "x$host_cpu" = xx86_64; then
CFLAGS="-m32 $CFLAGS"
fi
テスト中の3つの変数（x $ enable_maintainer_mode、x $ CFLAGS、x $ host_cpu）に関する情報が見つかりません。 AM_MAINTAINER_MODEマクロを実行した後にこれらの変数が生成されますか？もしそうなら、彼らに関する詳細情報はどこで見つけることができますか？
また、AM_MAINTAINER_MODEモードの目的は何ですか？
私が知る限り、デフォルトでは無効になっています。
- ユーザーが「configure」を実行し、すべての依存関係が満たされていない場合（Automakeバージョン、ツール、ライブラリなど）、終了してもはや進行しません。
- ユーザーが「configure」を実行し、すべての依存関係が満たされると、「make」ファイルを生成するconfig.statusスクリプトを生成して実行します。
- ユーザーは-enable-maintainer-modeオプションを使用してこの設定を上書きできます。これにより、さまざまなAutotoolファイル（configure.ac、Makefile.amなど）を変更でき、ビルドシステムはこれらの変更を反映するために更新する必要があるファイルを再生成しようとします（Autotoolsは古いファイルを見つけてそれに応じて更新します。 ）。 ）。
このモードを無効にする方が良い理由を理解しています。この機能を有効にする理由はありますか？
ベストアンサー1
一般的なアイデアは、AM_MAINTAINER_MODEプロジェクトを処理する2つの方法があるということです。 1つは、ユーザーが「のみ」プロジェクトをビルドおよびインストール（ソースベースのアーティファクトを使用したインストール）し、ビルドに触れることなくプロジェクトコードを変更する方法です。システムは、他のユーザーがビルド出力に反映したいプロジェクトのすべての変更です。
したがって、無効にすると、対応するAM_MAINTAINER_MODEソースファイル（等）が変更されても、等のファイルはconfigure再構築されません。これの利点は、ユーザーが必要なビルドツールを必要とせず、ツール自体に対する変更を処理する必要がないことです（現在の自動化ツールを使用して古い複雑なプロジェクトを再構築しようとした人に連絡してください）。欠点は、特定のファイルに対する変更は無視されるため、ユーザーはそのファイルをすべて手動で更新する必要があることです。 （これがインターネットで見られる多くのパッチに次の変更が含まれている理由です。Makefile.inconfigure.acMakefile.amMakefile.am そして Makefile.in時にはMakefile。 )
AM_MAINTAINER_MODE有効にすると、ファイルに対するすべての変更が考慮されるという利点があります。欠点は、ユーザーが実際のソースファイルが何であるかを知る必要があることです。メンテナンスモードを変更しMakefile.inて再構築すると、変更が失われる可能性があります。
今、一般的な合意は、実際のソースから再構築する方が良いことで、メンテナンスモードは良い考えではないということです。 （自動車メーカーのFAQ参考用。 ）これは、すべてのユーザーが突然再構築に必要なすべてのツールを持っている必要があるわけではありません。すべて;プロジェクトがリリースアーティファクトに生成されたファイルを提供している場合、タイムスタンプが良好であれば、ユーザーはそのファイルを再構築する必要はありません。