他のいくつかのシステムに付属する make プログラムには、GNU make では実装されていない機能がいくつか備わっています。とはいえ、make の仕様を定める POSIX.2 規格(IEEE Standard 1003.2-1992)では、これらの機能はどれも必須とされていません。
‘file((entry))’ という形式のターゲットは、アーカイブファイル file のメンバを表します。ただしそのメンバは名前で選ばれるのではなく、リンカシンボル entry を定義しているオブジェクトファイルであるかどうかによって選ばれます。
この機能を GNU make に取り入れなかったのは、アーカイブファイルのシンボルテーブルという内部フォーマットに関する知識を make に持たせるのが、モジュール性を損なうからです。アーカイブシンボルディレクトリの更新を参照してください。
(サフィックスルールで使われる)サフィックスのうち末尾が ‘~’ という文字で終わるものは、System V の make では特別な意味を持ちます。それらは、‘~’ を取り除いた名前のファイルに対応する SCCS ファイルを指します。例えば、サフィックスルール ‘.c~.o’ は、SCCS ファイル s.n.c からファイル n.o を生成します。あらゆる場合に対応するには、この種のサフィックスルールを一式そろえて用意する必要があります。古めかしいサフィックスルールを参照してください。
GNU make では、このようなケース一式は、SCCS から取り出すための 2 つのパターンルールと、ルール連鎖という汎用的な機能の組み合わせによって処理されます。暗黙のルールの連鎖を参照してください。
System V や 4.3 BSD の make では、VPATH 探索(前提条件を探すためのディレクトリ探索を参照してください)で見つかったファイルは、レシピの中で名前が書き換えられます。私たちは、常に自動変数を使うほうがずっとすっきりしており、それによってこの機能は不要になると考えています。
一部の Unix の make では、ルールの前提条件に現れる自動変数 $* が、なんとそのルールのターゲットのフルネームに展開されるという、驚くほど奇妙な「機能」を持っています。Unix の make 開発者がいったい何を考えてこんなことをしたのか、私たちには想像もつきません。これは $* の通常の定義とまったく一貫していません。
一部の Unix の make では、暗黙のルールの探索(暗黙のルールを使うを参照してください)が、レシピを持たないターゲットだけでなく、どうやらすべてのターゲットに対して行われるようです。そのため、次のような書き方ができてしまいます:
foo.o:
cc -c foo.c
すると Unix の make は、foo.o が foo.c に依存していると気を利かせて推測します。
私たちは、このような使い方は壊れていると考えています。make における前提条件の性質は(少なくとも GNU make では)明確に定義されており、このようなことをするのは、そのモデルにそぐわないのです。
GNU make には、EFL プログラムをコンパイルまたは前処理するための組み込みの暗黙のルールは一切含まれていません。もし EFL を使っているという方の声が届けば、喜んで追加します。
SVR4 の make では、サフィックスルールをレシピなしで指定でき、それが空のレシピを持つものとして扱われるようです(空のレシピを使うを参照してください)。例えば、次のように書くと:
.c.a:
組み込みの .c.a サフィックスルールを上書きできます。
私たちは、レシピを持たないルールは常に、単にターゲットの前提条件リストに追加するだけ、というほうがすっきりしていると考えています。GNU make で上記の例と同じ振る舞いを得たければ、次のように簡単に書き換えられます:
.c.a: ;
一部のバージョンの make は、‘-k’ が指定されている場合を除き、シェルを ‘-e’ フラグ付きで起動します(プログラムのコンパイルをテストするを参照してください)。‘-e’ フラグは、実行したプログラムのいずれかが 0 以外のステータスを返したらすぐに終了するよう、シェルに指示するものです。私たちは、レシピの各行がそれぞれ単独で成り立つように書き、こうした特別な扱いを必要としないほうがすっきりしていると考えています。