Makeを直接使用することは廃止されたと見なされていますか？
したがって、メイクファイルを直接作成すること、および2015年にそれを行うのはばかげたことであることについて、多くのコメント/投稿/その他に出くわしています。CMakeなどのツールを知っており、実際にCMakeを頻繁に使用しています。実は、CMakeはMakefileを作成しているだけであり、自分で行うという面倒な作業を取り除くのに役立ちます。もちろん、それは他の多くの素晴らしい機能を追加します...しかし、それでも結局はMakefileです。
だから私の質問は、Makeユーティリティ全体を指すmakeに関する「時代遅れの」話ですか、それとも単に自分のMakefileを手動で作成するという考えですか？ IDEをC/C++開発にまったく使用していません（単なるemacs））ので、常にMakefileを作成しています。
Makeが古くなっていると考えられる場合、C/C++開発者は小規模な個人プロジェクトを構築するために何を使用すべきですか？
大きな違いは、CMakeがクロスプラットフォームメタビルドシステムであることです。 1つのCMakeプロジェクトで、通常のUnix/Linuxメイクファイル、WindowsのVisual Studioプロジェクト、MacのXCodeプロジェクト、および使用またはサポートする可能性のあるほとんどすべての非メタビルドシステムを生成できます。
Makeを直接使用することも、手動でmakefileを編集することも「廃止された」とは言えませんが、Windowsへの移植を必要としないUnix/Linuxのもので作業している場合を除き、これらはおそらく実行すべきではありません。 Windows以外に移植したい場合は、Visual Studioプロジェクトファイルを直接編集しないでください。移植性に興味がある場合は、SconsやCMakeなどのメタビルドシステムについて学ぶ価値があります。
makeは本当に時代遅れですか？
私はそうは思いません。最後に、makeは、変更されたソースの条件付きコンパイルなど、必要なすべての機能を提供するのに十分強力です。 makeが古くなっていると言うことは、カスタムリンカースクリプトの記述が古いと言ったことと同じです。
しかし、生のmakeが提供していないのは、パラメトリックヘッダーの生成、統合されたテストフレームワーク、または一般的な条件付きライブラリなど、快適さのための拡張機能とストックライブラリです。
一方、CMakeは、一般的なELFライブラリと実行可能ファイルを生成するように直接調整されています。事前定義された手順から離れるときはいつでも、独自のMakefileをハックするのと同じようにCMakeのハッキングを開始する必要があります。
ELFローダーを知っているシステムの平均的なアプリケーションだけでなく、C++ではるかに多くを作成できることを考えると、CMakeはすべてのシナリオに適しているとは限りません。ただし、このような標準化された環境で作業している場合、CMakeまたはこれらの他の最新のスクリプトジェネレータフレームワークは、間違いなくあなたの親友です。
これは常に、アプリケーションの専門性、およびCMakeフレームワークの構造がワークフローにどの程度適合するかによって異なります。
むかしむかし、高級言語は単なるアイデアでした。人々はコンパイラを実装しようとしました。当時、ハードウェアには厳しい制限がありました。グラフィカルツールがなかったため、「プレーンテキスト」が入力ファイル形式に使用されていました。通常、コンピューターには非常に少量のRAMがあったため、ソースコードを細かく分割し、コンパイラーを別々のユーティリティ（プリプロセッサー、コンパイラー、アセンブラー、リンカー）に分割しました）; CPUは遅くて高価なので、高価な最適化などは行えません。
もちろん、多くのソースファイルと多くのユーティリティを使用して多くのオブジェクトファイルを作成しているため、手動で何かを作成するのは面倒です。ツールの設計上の欠陥の回避策（ハードウェアの制限が厳しいため）として、人々は自然にスクリプトの作成を開始し、面倒な作業の一部を取り除きました。
悲しいことに、スクリプトは扱いにくく面倒でした。スクリプトの問題（ハードウェアの制限によるツールの設計上の欠陥の回避策）を回避するために、人々はmakeのようなものを簡単にするユーティリティを発明しました。
しかしながら; makefileは扱いにくく厄介です。 makefileの問題（ハードウェアの制限によるツールの設計上の欠陥の回避策）を回避するために、自動生成されたmakefileの実験を開始しました。コンパイラーに依存関係を生成させるなどのことから始めます。 auto-confやcmakeなどのツールに至るまで。
これが私たちが今いるところです：限られたハードウェアによって引き起こされたツールの設計欠陥のための回避策のための回避策のための回避策。
今世紀の終わりまでに、既存の山の上に「回避策のための回避策」の層がさらにいくつかあると私は予想しています。皮肉なことに、これを引き起こしたハードウェアの深刻な制限は何十年も前に消え、私たちがこのような古風な混乱を今でも使用している唯一の理由は、「これが常に行われている方法ですです。
make（ツールまたはMakefileを介した直接使用）は、特に「小規模な個人プロジェクト」の場合、古くはありません。
もちろん、複数のプラットフォームを対象としたプロジェクトを含む、より大きなプロジェクトにも使用できます。 ターゲット固有の変数 を使用すると、さまざまなプラットフォーム用のビルド方法を簡単にカスタマイズできます。現在、Linuxディストリビューションにはクロスコンパイルツールチェーン（例 mingw-w64 ）が付属しているため、Linuxから完全なWindowsソフトウェアパッケージ（必要に応じてインストーラー付き）をビルドでき、すべてMakefileから駆動されます。
cmake や qmake などのツールは便利ですが、問題がないわけではありません。ライブラリ自体と一緒にアプリケーション自体を構築することは通常は問題ありません（ただし、qmakeがライブラリとそれを使用するプログラム間の適切な依存関係チェックを実行するのに常に問題がありました）が、残りの作業を行うときは常にこれらのツールの制約に苦労していますジョブ（インストーラーの作成、ドキュメントまたは翻訳ファイルの生成/インストール、アーカイブを共有ライブラリーに変換するなどの異常な処理など）。これはすべてmakeで行うことができますが、 依存関係の追跡 などの処理には少し労力が必要です。
Qt CreatorやEclipseなどのIDEもMakefileベースのプロジェクトをインポートできるため、IDEを使用する開発者と共有できます。 Qt Creator IDEはC++ IDEとして優れていると思いますが、Emacsでより効果的になるようにしばらく時間を費やした後、Adaの開発を進めているので、私は自分自身を好みますmakeに関する質問に戻るために、Makefileのリンク後のステップとして、TAGSファイルを更新します（Emacsの symbol navigation の場合）。 M-x visit-tags-table：
find $(SRC_DIR) $(TEST_DIR) -regex ".*\.[ch]\(pp\)?" -print | etags -
またはAda開発の場合：
find $(SRC_DIR) $(TEST_DIR) -name "*.ad?" -print | etags -
この回答は@lxrecの回答を補完します。
Makefileは、ソースコードからプログラム/ライブラリを作成するだけでなく、さまざまな目的で使用できます。 CMakeやautotoolsなどのビルドシステムは、コードを取得し、ユーザーのプラットフォームに適合するようにビルドします（つまり、ライブラリを見つけるか、正しいコンパイルオプションを指定します）。たとえば、次のようないくつかのリリースタスクの自動化に役立つメイクファイルを用意できます。gitから派生したバージョンでコードを含むZipファイルを作成します。コードに対してテストを実行します。上記のZipファイルをホスティングサービスにアップロードします。一部のビルドシステム（automakeなど）は、これを行う簡単な方法を提供する場合と、提供しない場合があります。
このためにメイクファイルを使用する必要があると言っているのではなく、そのようなタスクにはスクリプト言語（Shell、pythonなど））を使用できます。
特に次のような場合、人間が書いたMakefile- sは廃止されたとは思いません。
- pOSIX makeを使用すると、ポータブル
Makefile - またはGNU make 4を使用すると、多くの非常に興味深い機能、特にGUILEスクリプタビリティが提供されます。これにより、
Makefileジェネレーターによって提供される優れた機能を効率的にコーディングできます（ autotoolsまたはCmakeの機能は、GNU make）のGuileカスタマイズによって簡単に記述できます。もちろん、支払う価格はGNU make 4（not大したこと、私見）。
Makefileは、テキストファイルが廃止されたのと同じように、廃止されていません。すべてのデータをプレーンテキストで保存することが常に正しい方法であるとは限りませんが、必要なのがTodoリストだけであれば、プレーンテキストファイルで問題ありません。より複雑なものについては、MarkdownやXML、カスタムバイナリ形式などのより複雑な形式が必要になる場合がありますが、単純な場合はプレーンテキストで十分です。
同様に、必要なものがg++ -g src/*.c -o blah -W -Wall -Werror && ./blah常に、手書きのMakefileが最適です！
移植性が高く、自分で移植性を管理する必要がないものを構築したい場合は、Autotoolsのようなものを使用して、適切なMakefileを生成できます。 Autotoolsは、さまざまなプラットフォームでサポートされている機能を検出します。 Autotoolsで構築された標準C89で記述されたプログラムは、事実上どこでもコンパイルされます。