Makeを直接使用することは時代遅れと見なされますか？[閉まっている]

ですから、メイクファイルを直接作成することや、2015年にそれを行うのは馬鹿げたことです。CMakeなどのツールを知っており、実際にCMakeを頻繁に使用しています。大切なのは、CMakeはMakefileを作成して、自分でそれを行うという退屈な作業をなくすことです。もちろん、それは他の多くの素晴らしい機能を追加します...しかし、最終的にはまだMakefileです。

だから私の質問は、Makeユーティリティ全体を指すmakeに関する「時代遅れの」話ですか、それとも自分のMakefileを手動で書くというアイデアですか？私はC / C ++開発にIDEをまったく使用しません（ちょうどemacs）ので、常にMakefileを作成しました。

Makeが古いと見なされる場合、C / C ++開発者は小さな個人プロジェクトを構築するために何を使用すべきですか？

大きな違いは、CMakeがクロスプラットフォームのメタビルドシステムであることです。単一のCMakeプロジェクトは、通常のUnix / Linuxメイクファイル、Windows用のVisual Studioプロジェクト、Mac用のXCodeプロジェクト、および使用またはサポートする可能性のある他のほぼすべての非メタビルドシステムを生成できます。

makeを直接使用したり、makefileを手動で編集したりすることは「時代遅れ」とは言いませんが、Windowsに移植する必要のないUnix / Linuxの作業をしているのでなければ、おそらくそうすべきではありません非Windowsに移植する場合は、Visual Studioプロジェクトファイルを直接編集しないでください。移植性に興味がある場合は、SconsやCMakeなどのメタビルドシステムを学ぶ価値があります。

されてmake、本当に古いですか？

そうは思いません。最終的に、makeは、変更されたソースなどの条件付きコンパイルなど、必要なすべての機能を提供するのに十分強力です。言ってmake古いされた、書き込みカスタムリンカスクリプトが古いたと言っと同じになります。

しかし、raw makeが提供しないのは、拡張された機能と、パラメトリックヘッダー生成、統合テストフレームワーク、または一般的な条件付きライブラリなどの快適さのためのストックライブラリです。

一方、CMake汎用ELFライブラリと実行可能ファイルを生成するように直接調整されています。事前定義された手順から離れるたびにCMake、自分のMakefileをハッキングするのと同じように、ハッキングを開始する必要があります。

ELFローダーを知っているシステムの平均的なアプリケーションよりもC ++ではるかに多く作成できることを考えると、CMake確かにすべてのシナリオに適しているわけではありません。ただし、このような標準化された環境で作業している場合、CMakeまたはこれらの他の最新のスクリプトジェネレータフレームワークが間違いなく親友です。

それは常に、アプリケーションの専門性と、CMakeフレームワークの構造がワークフローにどの程度適合するかによって異なります。

むかしむかし、高レベル言語は単なるアイデアでした。人々はコンパイラを実装しようとしました。当時、ハードウェアには厳しい制限がありました。グラフィカルツールがなかったため、入力ファイル形式に「プレーンテキスト」が使用されていました。通常、コンピューターのRAMは非常に少ないため、ソースコードを細かく分割する必要があり、コンパイラーは個別のユーティリティ（プリプロセッサー、コンパイラー、アセンブラー、リンカー）に分割されました。CPUは低速で高価だったため、高価な最適化などを行うことができませんでした。

もちろん、多くのソースファイルと多くのユーティリティを使用して多くのオブジェクトファイルを作成しているため、手動で何かをビルドするのは面倒です。ツールの設計上の欠陥（ハードウェアが非常に限られていることが原因）の回避策として、人々は自然にスクリプトを記述し始めて、面倒な作業の一部を取り除きました。

悲しいことに、スクリプトは厄介で面倒でした。スクリプトの問題（ハードウェアが限られていることによるツールの設計上の欠陥の回避策）を回避するために、人々はやがて物事を簡単にするユーティリティを発明しましたmake。

しかしながら; メイクファイルは厄介で面倒です。メイクファイルの問題（ハードウェアの制限によるツールの設計上の欠陥の回避策でした）を回避するために、人々は自動生成されたメイクファイルの実験を始めました。コンパイラーに依存関係を生成させるなどのことから始めます。auto-confやcmakeなどのツールに至るまで。

これが現在の状況です。ハードウェアの制限が原因のツールの設計欠陥の回避策の回避策の回避策。

世紀の終わりまでに、既存のパイルの上に「回避策のための回避策」の層がさらにいくつかあることを期待しています。皮肉なことに、このすべてを引き起こしたハードウェアの厳しい制限は何十年も前になくなり、今でもこのような古風な混乱を使用している唯一の理由は「これが常に行われている方法」です。

make （ツールまたはMakefileを介したツールの直接使用）は、特に使用する「小規模な個人プロジェクト」にとっては古くありません。

もちろん、複数のプラットフォームを対象とするプロジェクトを含む、より大きなプロジェクトにも使用できます。ターゲット固有の変数あなたは簡単にあなたが別のプラットフォーム用にビルド方法をカスタマイズすることができます。現在、Linuxディストリビューションにはクロスコンパイルツールチェーン（例：mingw-w64）が付属しているため、Makefileから駆動される完全なWindowsソフトウェアパッケージ（必要に応じてインストーラーを使用）をビルドできます。

cmakeやqmakeなどのツールは便利ですが、問題がないわけではありません。ライブラリと一緒にアプリケーション自体を構築するのに通常は問題ありません（ただし、ライブラリとそれらを使用するプログラム間でqmakeが適切に依存関係をチェックするのに常に問題がありました）ジョブ（インストーラーの作成、ドキュメントまたは翻訳ファイルの生成/インストール、アーカイブを共有ライブラリーに変換するなどの異常なことを行うなど）。このすべてはで行うことができますがmake、依存関係の追跡などには少し手間がかかります。

Qt CreatorやEclipseなどのIDEもMakefileベースのプロジェクトをインポートできるため、IDEを使用する開発者と共有できます。Qt Creator IDEはC ++ IDEとして優れていると思いますが、Emacsでより効果的になるために少し時間を費やした後、Adaの開発をさらに進めているので、すべてにEmacsを好むことに気づきました。makeMakefileのポストリンクステップとしてについての質問に戻るために、（Emacs でのシンボルナビゲーション用の）TAGSファイルを更新し、次をロードし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など）は、これを簡単に行う方法を提供する場合もあれば、そうでない場合もあります。

このためにメイクファイルを使用する必要があるというわけではありません。そのようなタスクにはスクリプト言語（シェル、Pythonなど）を使用できます。

Makefile特に次の場合、人間が書いたものは時代遅れだとは思いません。

1. POSIX makeを使用すると、ポータブルな Makefile
2. またはGNU make 4を使用すると、多くの非常に興味深い機能、特にMakefileジェネレーターによって提供される派手な機能を効率的にコーディングできるGUILE スクリプタビリティが得られます）。もちろん、支払う代償はGNU make 4を要求することです（大したことではない、私見）。

テキストファイルが廃止されていないのと同様に、Makefileは廃止されていません。すべてのデータをプレーンテキストで保存することが常に正しい方法とは限りませんが、必要なのがTodoリストだけであれば、プレーンテキストファイルで十分です。より複雑なものには、MarkdownやXMLなどのより複雑な形式、またはカスタムバイナリ形式などが必要ですが、単純な場合はプレーンテキストで問題ありません。

同様に、常に書き出すことを避けたい場合は、g++ -g src/*.c -o blah -W -Wall -Werror && ./blah手書きのMakefileが最適です！

移植性を自分で管理する必要のない、移植性の高いものを構築したい場合は、Autotoolsのようなものが適切なMakefileを生成することを望むでしょう。Autotoolsは、さまざまなプラットフォームでサポートされている機能を検出します。Autotoolsで構築された標準C89で書かれたプログラムは、事実上どこでもコンパイルできます。

プロジェクトが単純で、ファイルの数が非常に少ない場合は、メイクファイルは必要ありません。

ただし、プロジェクトが複雑で、多数のメモリ領域を使用し、多くのファイルがある場合、各メモリ領域をアドレス可能なメモリの適切な場所に配置する必要があります。 1つのファイルに作成され、

最小限の手間とキー入力ミスの可能性で、古いファイル/コンパイル/リンク/インストールを消去したい場合、makefileは本当に有益です。

「現実世界」のプロジェクトに入ると、たった1つまたは2つのファイルではなく、数百のファイルになります。メイクファイルは常に正しいアクションを実行し、（デバッグ後）不要なアクションは実行しないため、1つの単純なコマンドを入力するだけで、メイクファイルがすべての作業を実行します。