SIMPLE C ++ Makefileの作成方法


303

Makefileを使用してプロジェクトのすべてをまとめる必要がありますが、教授はその方法を教えてくれませんでした。

ファイルは1つだけですa3driver.cpp。ドライバーは、場所からクラスをインポートし"/user/cse232/Examples/example32.sequence.cpp"ます。

それでおしまい。その他はすべてに含まれてい.cppます。

と呼ばれる実行可能ファイルを作成する単純なMakefileを作成するにはどうすればよいa3a.exeですか?


9
.EXEなので、間違いなくWindowsです。考え直してみると...パスはUnixスタイルです。おそらくMingw-32を使用しています。
Nathan Osman

2
はぁ。あなたはそれらを決して使用しない場合でも、あなたはすべての貿易の基本を学ぶ必要があると思います。ものの仕組みを理解する必要があります。ただし、EclipseなどのIDEで常に開発する可能性は高いです。簡単な1行の場合はここで答えが得られ、Webチュートリアルもたくさんありますが、詳細な知識が必要な場合は、O'reillyの本(ほとんどのs / wトピックと同じ)に勝るものはありません。amazon.com/Managing-Projects-Make-Nutshell-Handbooks/dp/…amazon、half.com、betterworldbooks eBayから2番目のハンドコピーを選んでください
Mawgはモニカを

2
@Dennisによって投稿されたリンクは現在無効になっていますが、同じ資料がこのarchive.orgページにあります
ギルヘルメサロメ2018

私はこの人の考えを好みます。(hiltmon.com/blog/2013/07/03/…)プロジェクト構造は、必要に応じて簡単に変更できます。また、開発者の時間をautomake / autoconf以外の時間に費やす必要があることにも同意します。これらのツールは適切な場所にありますが、おそらく内部プロジェクト用ではありません。このようなプロジェクト構造を生成するスクリプトを作成しています。
荒巻大輔

@GuilhermeSaloméおかげで、これは最高のシンプルで完全なチュートリアルだと思います。
Hareen Laks

回答:


560

これはUnix用であるため、実行可能ファイルには拡張子がありません。

注意すべきことの1つroot-configは、正しいコンパイルとリンクのフラグを提供するユーティリティです。ルートに対してアプリケーションを構築するための適切なライブラリ。これは、このドキュメントの元の読者に関する詳細です。

メイク・ミー・ベイビー

またはあなたが初めて作ったときのことを決して忘れません

makeの紹介と簡単なmakefileの書き方

メイクとは?そして、なぜ私は気にする必要がありますか?

Makeと呼ばれるツールは、ビルド依存関係マネージャーです。つまり、ソースファイル、オブジェクトファイル、ライブラリ、ヘッダーなどのコレクションからソフトウェアプロジェクトを取得するために、どのコマンドをどの順序で実行する必要があるかを知ることができます---一部は変更されている可能性があります最近---そして、それらをプログラムの正しい最新バージョンに変える。

実際、Makeは他の目的にも使用できますが、それについては説明しません。

簡単なMakefile

を含むディレクトリがtool tool.cc tool.o support.cc support.hhあり、 support.oに依存し、とroot呼ばれるプログラムにコンパイルされることになっているtoolとします。また、ソースファイルをハッキングしていて(既存のものtoolは現在古くなっていることを意味します)、プログラムをコンパイルします。

これを自分で行うには

  1. support.ccまたはのどちらかsupport.hhが新しいかどうかを確認し、新しいsupport.o場合は次のようなコマンドを実行します。

    g++ -g -c -pthread -I/sw/include/root support.cc
  2. support.hhまたはのどちらかtool.ccが新しいかどうかを確認し、新しいtool.o場合は次のようなコマンドを実行します。

    g++ -g  -c -pthread -I/sw/include/root tool.cc
  3. tool.oがより新しいかどうかを確認し、新しい場合はtool次のようなコマンドを実行します

    g++ -g tool.o support.o -L/sw/lib/root -lCore -lCint -lRIO -lNet -lHist -lGraf -lGraf3d -lGpad -lTree -lRint \
    -lPostscript -lMatrix -lPhysics -lMathCore -lThread -lz -L/sw/lib -lfreetype -lz -Wl,-framework,CoreServices \
    -Wl,-framework,ApplicationServices -pthread -Wl,-rpath,/sw/lib/root -lm -ldl

ふew!なんて面倒なことでしょう!覚えなければならないことがたくさんあり、間違いをする可能性もいくつかあります。(ところで、ここに表示されるコマンドラインの詳細は、ソフトウェア環境によって異なります。これらのコマンドラインは私のコンピューターで動作します。)

もちろん、3つのコマンドすべてを毎回実行することもできます。それは機能しますが、実質的なソフトウェアにうまく拡張できません(私のMacBookでゼロからコンパイルするのに15分以上かかるDOGSなど)。

代わりに、次のmakefileようなファイルを作成できます。

tool: tool.o support.o
    g++ -g -o tool tool.o support.o -L/sw/lib/root -lCore -lCint -lRIO -lNet -lHist -lGraf -lGraf3d -lGpad -lTree -lRint \
        -lPostscript -lMatrix -lPhysics -lMathCore -lThread -lz -L/sw/lib -lfreetype -lz -Wl,-framework,CoreServices \
        -Wl,-framework,ApplicationServices -pthread -Wl,-rpath,/sw/lib/root -lm -ldl

tool.o: tool.cc support.hh
    g++ -g  -c -pthread -I/sw/include/root tool.cc

support.o: support.hh support.cc
    g++ -g -c -pthread -I/sw/include/root support.cc

makeコマンドラインで入力するだけです。上記の3つのステップが自動的に実行されます。

ここでインデントされていない行は「ターゲット:依存関係」という形式であり、依存関係のいずれかがターゲットよりも新しい場合は、関連するコマンド(インデントされた行)を実行する必要があることをMakeに伝えます。つまり、依存関係の行は、さまざまなファイルの変更に対応するために再構築する必要があるもののロジックを記述しています。support.cc変更があった場合support.o、再構築する必要がありますが、そのままにしておくことがtool.oできます。support.o変更をtool再構築する必要がある場合。

各依存関係行に関連付けられたコマンドは、タブ(下記を参照)でオフに設定され、ターゲットを変更する必要があります(または変更時間を更新するために少なくともタッチします)。

変数、組み込みルール、その他の便利な機能

この時点で、makefileは実行する必要のある作業を単に記憶しているだけですが、必要なコマンドをすべて完全に把握して入力する必要がありました。それはそのようである必要はありません:Makeは、変数、テキスト操作関数、およびこれをはるかに簡単にすることができる多数の組み込みルールを備えた強力な言語です。

変数を作る

make変数にアクセスするための構文は$(VAR)です。

Make変数に割り当てる構文は次のとおりですVAR = A text value of some kind (またはVAR := A different text value but ignore this for the moment)。

メイクファイルの次の改良版のようなルールで変数を使用できます。

CPPFLAGS=-g -pthread -I/sw/include/root
LDFLAGS=-g
LDLIBS=-L/sw/lib/root -lCore -lCint -lRIO -lNet -lHist -lGraf -lGraf3d -lGpad -lTree -lRint \
       -lPostscript -lMatrix -lPhysics -lMathCore -lThread -lz -L/sw/lib -lfreetype -lz \
       -Wl,-framework,CoreServices -Wl,-framework,ApplicationServices -pthread -Wl,-rpath,/sw/lib/root \
       -lm -ldl

tool: tool.o support.o
    g++ $(LDFLAGS) -o tool tool.o support.o $(LDLIBS)

tool.o: tool.cc support.hh
    g++ $(CPPFLAGS) -c tool.cc

support.o: support.hh support.cc
    g++ $(CPPFLAGS) -c support.cc

これはもう少し読みやすいですが、それでも多くの入力が必要です

関数を作る

GNU makeは、ファイルシステムまたはシステム上の他のコマンドからの情報にアクセスするためのさまざまな機能をサポートしています。この場合、我々は、に興味のある$(shell ...)引数(複数可)の出力に展開された、と$(subst opat,npat,text)のすべてのインスタンスを置換するopatnpat、テキストインチ

これを利用すると、次のようになります。

CPPFLAGS=-g $(shell root-config --cflags)
LDFLAGS=-g $(shell root-config --ldflags)
LDLIBS=$(shell root-config --libs)

SRCS=tool.cc support.cc
OBJS=$(subst .cc,.o,$(SRCS))

tool: $(OBJS)
    g++ $(LDFLAGS) -o tool $(OBJS) $(LDLIBS)

tool.o: tool.cc support.hh
    g++ $(CPPFLAGS) -c tool.cc

support.o: support.hh support.cc
    g++ $(CPPFLAGS) -c support.cc

これは入力が簡単で、はるかに読みやすくなっています。

そのことに注意してください

  1. 各オブジェクトファイルと最終的な実行可能ファイルの依存関係はまだ明示的に述べています
  2. 両方のソースファイルのコンパイルルールを明示的に入力する必要がありました

暗黙的およびパターンのルール

通常、すべてのC ++ソースファイルは同じように扱われるべきであり、Makeはこれを説明する3つの方法を提供します。

  1. 接尾辞規則(GNU makeでは廃止されたと見なされますが、下位互換性のために残されています)
  2. 暗黙のルール
  3. パターンルール

暗黙のルールが組み込まれており、そのいくつかを以下で説明します。パターンルールは次のような形式で指定されます

%.o: %.c
    $(CC) $(CFLAGS) $(CPPFLAGS) -c $<

これは、表示されたコマンドを実行することによってオブジェクトファイルがCソースファイルから生成されることを意味します。ここで、「自動」変数$<は最初の依存関係の名前に展開されます。

組み込みルール

Makeには多数の組み込みルールがあります。つまり、非常に多くの場合、プロジェクトは非常に単純なmakefileでコンパイルできます。

Cソースファイル用のGNU make組み込みルールは、上記で示したものです。同様に、のようなルールでC ++ソースファイルからオブジェクトファイルを作成します$(CXX) -c $(CPPFLAGS) $(CFLAGS)

単一のオブジェクトファイルはを使用してリンクされますが$(LD) $(LDFLAGS) n.o $(LOADLIBES) $(LDLIBS)、複数のオブジェクトファイルをリンクする必要があるため、この場合は機能しません。

組み込みルールで使用される変数

組み込みのルールは一連の標準変数を使用するため、すべてのルールを書き直すことなく、ローカル環境情報(ROOTインクルードファイルの場所など)を指定できます。私たちにとって最も興味深いものは次のとおりです。

  • CC -使用するCコンパイラ
  • CXX -使用するC ++コンパイラ
  • LD -使用するリンカー
  • CFLAGS -Cソースファイルのコンパイルフラグ
  • CXXFLAGS -C ++ソースファイルのコンパイルフラグ
  • CPPFLAGS -Cプリプロセッサのフラグ(通常、コマンドラインで定義されたファイルパスとシンボルを含む)、CおよびC ++で使用
  • LDFLAGS -リンカーフラグ
  • LDLIBS -リンクするライブラリ

基本的なMakefile

組み込みルールを利用することにより、メイクファイルを次のように単純化できます。

CC=gcc
CXX=g++
RM=rm -f
CPPFLAGS=-g $(shell root-config --cflags)
LDFLAGS=-g $(shell root-config --ldflags)
LDLIBS=$(shell root-config --libs)

SRCS=tool.cc support.cc
OBJS=$(subst .cc,.o,$(SRCS))

all: tool

tool: $(OBJS)
    $(CXX) $(LDFLAGS) -o tool $(OBJS) $(LDLIBS)

tool.o: tool.cc support.hh

support.o: support.hh support.cc

clean:
    $(RM) $(OBJS)

distclean: clean
    $(RM) tool

特別なアクション(ソースディレクトリのクリーンアップなど)を実行するいくつかの標準ターゲットも追加しました。

makeが引数なしで呼び出されると、ファイルで見つかった最初のターゲット(この場合はすべて)が使用されますが、ターゲットに名前を付けてmake clean、この場合オブジェクトファイルを削除することもできます。

すべての依存関係はまだハードコーディングされています。

いくつかの不可解な改善

CC=gcc
CXX=g++
RM=rm -f
CPPFLAGS=-g $(shell root-config --cflags)
LDFLAGS=-g $(shell root-config --ldflags)
LDLIBS=$(shell root-config --libs)

SRCS=tool.cc support.cc
OBJS=$(subst .cc,.o,$(SRCS))

all: tool

tool: $(OBJS)
    $(CXX) $(LDFLAGS) -o tool $(OBJS) $(LDLIBS)

depend: .depend

.depend: $(SRCS)
    $(RM) ./.depend
    $(CXX) $(CPPFLAGS) -MM $^>>./.depend;

clean:
    $(RM) $(OBJS)

distclean: clean
    $(RM) *~ .depend

include .depend

そのことに注意してください

  1. ソースファイルの依存関係の行はなくなりました!?!
  2. .dependとdependに関連する奇妙な魔法があります
  3. あなたが行う場合はmake、その後ls -A、あなたは指定されたファイルを参照.dependメイク依存行のように見えるものが含まれています

その他の読書

バグと歴史的メモを知る

Makeの入力言語は空白を区別します。特に、依存関係に続くアクションラインはタブで始まる必要があります。しかし、一連のスペースは同じように見えます(実際、タブをスペースに、またはその逆に暗黙的に変換するエディターがあります)。その結果、Makeファイルは正しく見えても機能しません。これは早い段階でバグとして識別されましたが、(ストーリーは)すでに10人のユーザーがいるため、修正されませんでした。

(これは私が物理学の大学院生のために書いたwikiの投稿からコピーされました。)


9
依存関係を生成するこの方法は廃止され、実際には有害です。Advanced Auto-Dependency Generationを参照してください。
Maxim Egorushkin、2011

5
-pthreadフラグgccは必要なマクロを定義させるため、-D_REENTRANT不要です。
Maxim Egorushkin、2011

8
@jcoe依存関係を生成するために不要な追加のプリプロセッサパスを実行します。不要な作業を行うと、氷柱を溶かして熱を放散するだけでなく、より大きな規模で、宇宙の熱死に近づいています。
Maxim Egorushkin 2014

2
おそらく「有害」なことは少し多すぎますが、少なくともGCC 3以降では明示的な依存関係生成フェーズまたはターゲットが古くなっていることを考えると、私たちは全員、それらを通過する必要があると本当に思っています。bruno.defraine.net/techtips/makefile-auto-dependencies-with-gcc/…–
hmijailが辞任を悼む

2
実際、受け入れられた回答は、特定のソフトウェアに依存するべきではありません(root-config)。同じ機能を備えたより一般的な代替案がある場合は提案するか、単に除外する必要があります。最も頻繁に使用されるmakeマクロのリストと説明のため、私は反対票を投じませんでした。
緑のダイオード16

56

これは詳細な例を使うと簡単に習得できるといつも思っていました。セクションごとに、インデントされていない1行があり、セクションの名前と依存関係が表示されます。依存関係は、他のセクション(現在のセクションの前に実行されます)またはファイル(更新された場合に、次に実行するときに現在のセクションが再度実行されるようにする)のいずれかですmake

これは簡単な例です(タブを使用する必要がある場所で4つのスペースを使用していることに注意してください。StackOverflowではタブを使用できません)。

a3driver: a3driver.o
    g++ -o a3driver a3driver.o

a3driver.o: a3driver.cpp
    g++ -c a3driver.cpp

と入力makeすると、最初のセクション(a3driver)が選択されます。a3driverはa3driver.oに依存しているので、そのセクションに移動します。a3driver.oはa3driver.cppに依存しているため、a3driver.cppが最後に実行されてから変更された場合にのみ実行されます。実行されている(または実行されたことがない)場合、a3driver.cppを.oファイルにコンパイルしてから、a3driverに戻って最終的な実行可能ファイルをコンパイルします。

ファイルは1つしかないため、次のように減らすこともできます。

a3driver: a3driver.cpp
    g++ -o a3driver a3driver.cpp

最初の例を示したのは、メイクファイルの力を示しているからです。別のファイルをコンパイルする必要がある場合は、別のセクションを追加できます。次に、secondFile.cppを使用した例を示します(secondFile.hという名前のヘッダーに読み込まれます)。

a3driver: a3driver.o secondFile.o
    g++ -o a3driver a3driver.o secondFile.o

a3driver.o: a3driver.cpp
    g++ -c a3driver.cpp

secondFile.o: secondFile.cpp secondFile.h
    g++ -c secondFile.cpp

このように、secondFile.cppまたはsecondFile.hで何かを変更して再コンパイルすると、secondFile.cppのみが再コンパイルされます(a3driver.cppではありません)。または、a3driver.cppで何かを変更しても、secondFile.cppは再コンパイルされません。

ご不明な点がありましたらお知らせください。

「all」という名前のセクションと「clean」という名前のセクションを含めることも伝統的です。「all」は通常、すべての実行可能ファイルをビルドし、「clean」は.oファイルや実行可能ファイルなどの「ビルドアーティファクト」を削除します。

all: a3driver ;

clean:
    # -f so this will succeed even if the files don't exist
    rm -f a3driver a3driver.o

編集:私はあなたがWindowsを使っていることに気づきませんでした。私は、唯一の違いは変化していると思います-o a3driver-o a3driver.exe


私が使用しようとしている絶対コードは次のとおりです:p4a.exe:p4driver.cpp g ++ -o p4a p4driver.cppしかし、「セパレーターがありません」と表示されます。私はTABを使用していますが、それでもそれがわかります。何か案が?
降臨

2
私が知る限り、そのエラーメッセージはスペースがある場合にのみ表示されます。スペースで始まる行がないことを確認してください(スペース+タブでエラーが発生します)。それは私が..考えることができる唯一のことだ
ブレンダン・ロング

今後のエディターへのメモ:StackOverflowはタブを回答に編集してもタブをレンダリングできません。そのため、私のメモを「修正」しようとしないでください。
ブレンダンロング、

35

なぜ誰もがソースファイルをリストするのを好むのですか?簡単なfindコマンドで簡単に処理できます。

以下は、単純なC ++ Makefileの例です。.Cファイルを含むディレクトリにドロップして、次のように入力してくださいmake...

appname := myapp

CXX := clang++
CXXFLAGS := -std=c++11

srcfiles := $(shell find . -name "*.C")
objects  := $(patsubst %.C, %.o, $(srcfiles))

all: $(appname)

$(appname): $(objects)
    $(CXX) $(CXXFLAGS) $(LDFLAGS) -o $(appname) $(objects) $(LDLIBS)

depend: .depend

.depend: $(srcfiles)
    rm -f ./.depend
    $(CXX) $(CXXFLAGS) -MM $^>>./.depend;

clean:
    rm -f $(objects)

dist-clean: clean
    rm -f *~ .depend

include .depend

2
ソースファイルを自動で見つけない理由は、異なるファイルを必要とする異なるビルドターゲットを持つことができるためです。
hmijailは2015

同意した@hmijailだけでなく、コンパイル/リンクしたくない大量のソース/ヘッダーを含むサブモジュール...そして、徹底的な検索/使用が不適切な他の多くの状況は間違いありません。
エンジニア、

代わりに「ワイルドカード」ではなく「シェル検索」を使用するのはなぜですか?
ノーラン

1
@Nolanがソースディレクトリツリーでソースファイルを検索
AlejandroVD

13

2つのオプションがありました。

オプション1:最も単純なmakefile = NO MAKEFILE。

「a3driver.cpp」の名前を「a3a.cpp」に変更し、コマンドラインで次のように記述します。

nmake a3a.exe

以上です。GNU Makeを使用している場合は、「make」または「gmake」などを使用します。

オプション2:2行のmakefile。

a3a.exe: a3driver.obj
    link /out:a3a.exe a3driver.obj

3
これは、OPの環境の詳細についてそれほど多くのことを前提としない場合、優れた答えになります。はい、Windows上にありますが、それはを使用しているという意味ではありませんnmakelinkコマンドラインも非常に少なくとも文書1で特定のコンパイラに非常に具体的に見える、とすべきです。
tripleee

6

Makeファイルには、単一のコマンドでコンパイルしてリンクするか、コンパイル用に1つのコマンドとリンク用に1つのコマンドを使用するかに応じて、1つまたは2つの依存関係ルールがあります。

依存関係は、次のような規則のツリーです(インデントはタブでなければならないことに注意してください)。

main_target : source1 source2 etc
    command to build main_target from sources

source1 : dependents for source1
    command to build source1

そこなければならない目標のためのコマンドの後に空白行も、そしてそこになければならないコマンドの前に空白行も。makefileの最初のターゲットは全体的な目標であり、他のターゲットは、最初のターゲットがそれらに依存している場合にのみ構築されます。

したがって、メイクファイルは次のようになります。

a3a.exe : a3driver.obj 
    link /out:a3a.exe a3driver.obj

a3driver.obj : a3driver.cpp
    cc a3driver.cpp

6

私は提案します(インデントはタブであることに注意してください):

tool: tool.o file1.o file2.o
    $(CXX) $(LDFLAGS) $^ $(LDLIBS) -o $@

または

LINK.o = $(CXX) $(LDFLAGS) $(TARGET_ARCH)
tool: tool.o file1.o file2.o

後者の提案は、GNU Makeの暗黙のルールを再利用するため、少し優れています。ただし、機能させるには、ソースファイルの名前が最終的な実行可能ファイルと同じである必要があります(例:tool.cおよびtool)。

通知元を宣言する必要はありません。中間オブジェクトファイルは、暗黙のルールを使用して生成されます。その結果、これMakefileはCおよびC ++(およびFortranなど)でも機能します。

また、デフォルトでは、Makefile $(CC)がリンカーとして使用されています。$(CC)C ++オブジェクトファイルのリンクでは機能しません。それLINK.oだけのために変更します。Cコードをコンパイルする場合は、LINK.o値を強制する必要はありません。

もちろん、コンパイルフラグを変数CFLAGSに追加し、ライブラリをに追加することもできますLDLIBS。例えば:

CFLAGS = -Wall
LDLIBS = -lm

ワンサイドノート:あなたは外部ライブラリを使用する必要がある場合は、私がお勧めするのpkg-config設定を使用し、正しく設定するために、CFLAGSLDLIBS

CFLAGS += $(shell pkg-config --cflags libssl)
LDLIBS += $(shell pkg-config --libs libssl)

注意深い読者はMakefile、1つのヘッダーが変更されると、これが正しく再構築されないことに気付くでしょう。次の行を追加して問題を修正します。

override CPPFLAGS += -MMD
include $(wildcard *.d)

-MMDヘッダーの依存関係に関するMakefileフラグメントを含む.dファイルを構築できます。2行目はそれらを使用しています。

確かに、適切に作成されたMakefileには次のルールも含まれている必要がcleanありdistcleanます。

clean:
    $(RM) *.o *.d

distclean: clean
    $(RM) tool

はと$(RM)同等ですがrm -frm直接呼び出さないことをお勧めします。

allルールも理解されよう。機能するためには、ファイルの最初のルールである必要があります。

all: tool

installルールを追加することもできます:

PREFIX = /usr/local
install:
    install -m 755 tool $(DESTDIR)$(PREFIX)/bin

DESTDIRデフォルトでは空です。ユーザーは、別のシステムにプログラムをインストールするように設定できます(クロスコンパイルプロセスでは必須)。にパッケージPREFIXをインストールするために、複数のディストリビューションのパッケージメンテナーも変更される場合があります/usr

最後に、ソースファイルをサブディレクトリに配置しないでください。本当にそうしたい場合は、これMakefileをルートディレクトリに保存し、フルパスを使用してファイルを識別します(つまりsubdir/file.o)。

要約すると、完全なMakefileは次のようになります。

LINK.o = $(CXX) $(LDFLAGS) $(TARGET_ARCH)
PREFIX = /usr/local
override CPPFLAGS += -MMD
include $(wildcard *.d)

all: tool
tool: tool.o file1.o file2.o
clean:
    $(RM) *.o *.d
distclean: clean
    $(RM) tool
install:
    install -m 755 tool $(DESTDIR)$(PREFIX)/bin

終わり近く:ルール間に空行があってはいけませんか?John Knoellerの答えはそれを主張した。
Peter Mortensen、

make私が知っている実装(GNU MakeとBSD Make)では、ルール間に空の行は必要ありません。ただし、make独自のバグ^ W固有性を備えた実装が数多く存在します。
ジェローム・Pouiller

5

フライドマッドの答えを使いました。私はしばらくこれを調べました、そしてそれは始めるのに良い方法のようです。このソリューションには、コンパイラフラグを追加する明確に定義された方法もあります。私の環境、Ubuntuとg ++で動作するように変更を加えたので、もう一度答えました。より多くの実用的な例は、時には最高の教師です。

appname := myapp

CXX := g++
CXXFLAGS := -Wall -g

srcfiles := $(shell find . -maxdepth 1 -name "*.cpp")
objects  := $(patsubst %.cpp, %.o, $(srcfiles))

all: $(appname)

$(appname): $(objects)
    $(CXX) $(CXXFLAGS) $(LDFLAGS) -o $(appname) $(objects) $(LDLIBS)

depend: .depend

.depend: $(srcfiles)
    rm -f ./.depend
    $(CXX) $(CXXFLAGS) -MM $^>>./.depend;

clean:
    rm -f $(objects)

dist-clean: clean
    rm -f *~ .depend

include .depend

Makefileは非常に複雑なようです。私はそれを使用していましたが、g ++ライブラリでリンクしないことに関連するエラーを生成していました。この構成はその問題を解決しました。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.