python
のpep8
のように、プログラミング言語用のリンターがたくさんあることは知っていますが、makefile
のリンターに出くわしたことはありません。 makefile
sにそのようなリンターはありますか?
makefile
を使用するように成長するにつれて、それはより複雑で長くなり続けます。私にとっては、makefile
を読みやすくするためにリンターを用意するのが理にかなっています。
lint
の動作に似ているのは、コマンドラインオプション--warn-undefined-variables
だけです。
また、make file lintの場所もわかりません(「makefile lint」のWeb検索でここに到達しました)が、make filelintユーティリティを実装するための浅いアイデアフラグメントの不完全なリストがあります...
タブとスペースはmakeファイル内で異なるセマンティクスを持っているため、空白は読みやすさの1つの側面です。 Emacs makefile-mode
は、タブの間隔が不適切なmakeファイルを保存しようとすると、デフォルトで「疑わしい」行を警告します。たぶん、バッチモードでemacsを実行し、そのモードから解析および検証機能を呼び出すことが可能でしょう。誰かがそのようなmakefile lintユーティリティの実装を開始した場合、emacsLISPモードをチェックするのは興味深いかもしれません。
正しさのチェックについて、@ MarkGaleckはすでに--warn-undefined-variables
について言及しています。問題は、未定義であるが標準化された変数からの出力が多いことです。このアイデアを改善するために、単純なラッパーを追加して、これらの変数に関するメッセージをフィルターで除外し、実際のタイプミスを見つけることができます。この場合、make
はオプション--just-print
(別名-n
または--dry-run
)で実行して、ターゲットを構築するための実際のコマンドを実行しないようにすることができます。
Makeを--just-print
オプションで実行するときに変更を実行することはお勧めできません。 $(Shell ...)
関数呼び出しをgrepして、それらの関数内から何も変更されていないことを確認すると便利です。チェックできるものの最初の反復:$(Shell pwd)
およびその他の一般的な非破壊的使用は問題ありません。それ以外の場合は、手動チェックの警告を呼び出す必要があります。
$
の後に(
が続かない(おそらくPOSIX正規表現で表現された[$][^$(][[:space:]]
のようなもの)grepを実行して、$(V)ARIABLE
として解析され、作成者が意図したものではなく、スタイルも適切でない$VARIABLE
のようなケースをキャッチできます。
Makeファイルの問題は、$(Shell)
、$(call)
、$(eval)
、ルール評価などのネストされたすべての構造で非常に複雑になることです。結果は、環境やコマンドラインからの入力、またはmake呼び出しの呼び出しによって変わる可能性があります。また、より深いセマンティック分析を問題にする多くの暗黙のルールまたは他の定義があります。すべてを網羅するmakelintユーティリティは実現可能ではないと思います(おそらくmakeユーティリティ自体に組み込まれている場合を除く)が、特定の体系化されたガイドラインとヒューリスティックチェックはすでに実際に役立つことが証明されています。