".am.in"？それを生成せずに ".in"と書いても大丈夫ですか？

Question

簡単に言えば、開発中のプロジェクトの中にある "buildconf.py.am.in"ファイルを使いました。 autotoolsの専門家ではない（私はこの仕事のためにそれらを学ばなければならなかった）、これは私にとって非常に奇妙なようだ。その内部には2つのVAR=@VAR@と2つのVAR=[@]VAR[@]があります。

どのように ".am.in"が存在する可能性がありますか？私にとって、これは、.in（または.py、多分）を生成するために使用される.amを生成するために.inを書くことを意味します。それは「合法」か、それとも「固定」すべきか？したがって、configureのステップの後に、私はmakeプロセス中に.pyを生成するために使用される "buildconf.py.am"を持っています。以下の内容が含まれています。

do_subst = sed -e 's,\[@\]APP_VARDIR\[@\],$(localstatedir)/app/,g' \ 
    -e 's,\[@\]APP_LOGDIR\[@\],$(logdir),g' 

buildconf.py: buildconf.py.am 
    $(do_subst) < $(srcdir)/buildconf.py.am > buildconf.py 

「正常」または「許容」ですか？私はすべてを統合しようとしているので、すべてが「扱いにくく、更新するのが難しくなっているので、それは私にとって巨大な修正の1つのようです。

TY！

EDIT：例えばDATADIRまたはソフトインストールディレクトリとして

スクリプトはほとんど「プラグイン」で使用されるフォルダのパスを定義し、このように必要なもの。また、これらのプラグインで使用されるフォルダ構造を定義して、いわゆるプラグインのPythonコードでインポートできるようにします。さらに、これらの「プラグイン」は実際にはアプリケーションのサーバー/ルーティング層です。

• buildconf.py.am.inファイルは生成されず、手作業で書き込まれます。
• buildconf.py.amはそれができるかAC_CONFIG_FILESで他の人（の中で宣言されている？buildoncf.py.am.inファイル「次に作るためにbuildconf.py.am.in.inを生成するために使用される、その横にbuildconf.py.am.in.amがなければならない」伝えることになって...しかし、すべてです我々は欲しいと取得するbuildconf.pyです）;
• configureを実行すると、buildconf.py.amが生成されます。設定された変数は、mongoDBプラグインとWeb UIプラグインが提供されているかどうかを示す2つのブール値です。
• makeは、それが保持する定数が必要な場合にインポートされる最終的なbuildconf.pyを生成します。この段階では、configure段階で変数が展開される必要があるため、この時点で実行されます。

Answer 1

これはちょうど名前の問題かもしれないと思います。

通常.amファイルがMakefile.amによって含まれており、automakeによって拡張されているので、例えば、それらは非再帰的な全体的なビルドを維持しながら、ソースとターゲットのディレクトリごとの定義を持っているために使用されています。

あなたはインクルージョンはなくmakeによって実行されるように、Makefileレベルでのファイルが含まれていますが、.amが間違ってそのように聞こえるそれらを呼び出すことができます。

しかし、この場合はどちらでもありません。これはむしろ.in.inと呼ばれるべきです（そのようなスクリプトがいくつかありますが）。 makeフェーズの間にすべての置換を適用するだけで、処理を一度行う感覚はほぼ同じです。

私はおそらく、元の拡張が間違っていて、階層化されていますが、コードベースが分からないことが考えられます。