私は autoconf のファンではありませんが、原則として、(autoconf 以外の) configure スクリプトが、ユーザーが autoconf ベースのビルド システムに期待するものにできるだけ近い動作をするようにしています。GNU コーディング標準は、実際にはこのトピックに関してかなり合理的であり、autoconf/automake を使用せずに別の方法で互換性のあるインターフェースを提供する可能性について明示的に言及しています。
https://www.gnu.org/prep/standards/standards.html#Configuration
ただし、適切な説明が見つからない問題の 1 つは、CFLAGS を最適に処理する方法です。ユーザーのビジネスに関係のない重要なフラグ ( など-I$(srcdir)/inc
) は、configure スクリプトまたは makefile の CFLAGS に属していないことは明らかです。それらをオーバーライドすると、ビルドが完全に壊れてしまうからです。したがって、これらは makefile にハードコーディングするか、(検出が必要な場合は) configure に検出ロジックを配置しますが、上書きされないように CFLAGS の代わりに別の make 変数を介して渡します。
ただし、最善の処理方法についてはまだ不明ですが、最適化レベル/オプション、警告フラグ、デバッグなどのオプションのものです。フラグは、次のようなものによって有効にするか、他の make 変数に追加--enable-debug
または渡す必要がありますか? ユーザー提供のフラグと競合する場合はどうなりますか?--enable-warnings
CFLAGS
CFLAGS
多くのプロジェクトで、答えが「それをまったくいじらず、ユーザーに選択させるCFLAGS
」であることがわかりますが、私の使用例のいくつかは、ユーザーベースが一般的に興味を持っているプロジェクトです-すぐに使用できる最適化されたデバッグ構成。
編集:CFLAGS
私が忘れていたもう1つの問題:必須ではないが優先される特定のCFLAGSを検出して自動的に使用する場合、これはユーザーが環境で空白のままにした場合にのみ行うべきですか、それとも常に行うべきですか?