makefile編譯規定
① Ubuntu下面Makefile的使用方法
運行可執行文件hello
./hello
移除文件 rm hello
編譯文件得到可執行文件的同時,保留產生的中間文件
g++ -save-temps hello_world.cpp -o hello
單個文件編譯過程:
實際的編譯過程:預處理,對應臨時文件hello_world.ii
g++ -E hello_world.cpp -o preprocessed.ii
cat preprocessed.ii
預處理的工作主要包含去掉注釋,然後將我們include的庫tack上,以上過程使我們自己主動調用預處理器的過程
cat hello_world.ii
則展示了我們在第5)中編譯時保留的中間文件,兩者是一樣的
實際的編譯過程:這是真正的編譯過程compilation step,對應臨時文件hello_world.s(assembly code)
我們自己把.ii文件進行assembly code得到.s的方法。
g++ -S preprocessed.ii -o complied.s
.s文件是高級語言和機器語言之間的中間環節
實際的編譯過程:Assembly,將.s對應的assembly code轉換成.o對應的機器語言的過程,也叫machine-readable code或者object code
讓編譯器將.s文件assembly起來
g++ -c complied.s -o assembled.o
實際的編譯過程:最後一步Linking,產生最終的可執行文件。
"Undefined reference" errors are pretty much always linking errors, and you will probably have them. Remember this.
我們通過連接一堆.o文件,得到.exe文件的過程,命令:
g++ assembled.o -o hello_manual
多個文件編譯過程:
舉例,如果我們有定義一個class,然後我們的文件中包含dog.hpp,dog.cpp和main.cpp三個文件,然後我們只使用以下兩個命令:
g++ -c main.cpp -o main.o
g++ main.o dog_program
的話就會出錯,告訴我們undefined reference of dog::bark()
因為對於不同的.cpp文件,都要生成一個object file,也就是.o文件。所以如果我們用以下命令:
g++ -c main.cpp -o main.o
g++ -c dog.cpp
g++ dog.o main.o -o dog_program
的話,就不會出錯。
我們如果修改main.cpp中的內容的話,我們只需要重新用最後一個連接命令。但是,如果我們修改了dog class本身的內容的話,例如添加一個函數,我們就需要重新產生object file of dog.cpp,然後重新連接。
關於Make的介紹
用自己常用的記事本創建一個Makefile,並注意大小寫。在program對應的目錄下面。
gedit Makefile
Makefile裡面語句的書寫規則是
Target: tgt_dependency1 tgt_dependency2 ……
Command
所以dog.o和main.o對應的語句分別是:
dog.o: dog.hpp dog.cpp
g++ -c dog.cpp
main.o: main.cpp
g++ -c main.cpp
在Makefile中Tab是很重要的,所以不要忘記在command對應的第二行加Tab
Makefile的編譯順序
如果Makefile中有如下語句
animal_assembly : moose goose cat
command
moose : antlers hooves fur
command
goose : beak wings webbed_feet interest_in_bread
command
cat : whiskers evil_personality
command
我們可以看到animal_assembly的dependency是 moose goose cat。如果文件夾中存在moose goose cat的話,make命令只需要執行第一句就可以了。如果文件夾中缺少moose goose cat中的一個或者幾個,make命令執行的時候,需要先找到moose goose cat的生成方法,然後執行對應的命令,最後執行animal_assembly生成的命令。
moose : antlers hooves fur
command
animal_assembly : moose goose cat
command
goose : beak wings webbed_feet interest_in_bread
command
cat : whiskers evil_personality
command
如果Makefille是以上形式的話,我們只運行make的話,Makefile會只執行第一句,因為第一句的dependency都存在了,所以只把moose生成的命令執行完就好了。如果我們要生成animal_assembly,就要運行命令make animal_assembly。所以,我們需要把最重要的命令,我們最重要生成的object file對應的命令放在第一行。
所以我們的dog_program的完整的Makefile文件應該是:
dog_program: dog.o main.o
g++ dog.o main.o -o dog_program
dog.o: dog.hpp dog.cpp
g++ -c dog.cpp
main.o: main.cpp
g++ -c main.cpp
在Makefile的最後寫clean語句。
clean:
rm dog_program *.o
然後我們在命令窗口運行make clean的話,就會刪除文件夾中生成的可執行文件,和所有過程中產生的副產品。
對於Makefile中的dependency list,我們需要將每個object file的dependency list都寫好。因為make不負責檢查文件中的具體的語句,只負責執行Makefile中的語句。
dog_program:
g++ dog.o main.o -o dog_program
dog.o: dog.hpp dog.cpp
g++ -c dog.cpp
main.o: main.cpp
g++ -c main.cpp
如果像上面所示去掉dog_program的dependency list的話,運行make就會出錯,因為main是依賴於dog.cpp的。
如果文件中本身就存在dog.o和main.o的話,運行make不會出錯,因為make就是先check dog.o main.o是否存在,存在的話就直接運行。
所以,我們如果修改了main.cpp或者dog.cpp的話,我們需要重新生成dog.o和main.o。因為make是不管這個問題的。
make這個命令的功能就是執行Makefile中我們要求執行的語句,對結果沒有任何的預期,也不會檢查命令有沒有問題。所以,我們必須遵守Makefile書寫中的一些規則。
all : fill_file_with_nonsense
echo "I have mostly created a lot of junk today!"
fill_file_with_nonsense : create_file
echo "Hello, there is nothing important here" > silly_file
create_file :
touch silly_file touch是Unix中的典型命令,用於生成空的文件
move_file :
mv silly_file silly_file_new_name
delete_file :
rm _file
open_file :
gedit another_silly_file
clean :
touch junk1 junk2 junk3 junk4 junk5
really_clean :
rm junk*
如果想體驗的更加清楚,就可以運行這個文件中的內容,然後就知道make完全不會管結果是什麼,只是沒有腦子的執行命令。
解釋上面的內容:
Makefile的書寫規則。all: 放在第一句,把所以我們要生成executable依賴的Targets列出來,這樣我們需要的所有的文件都可以生成。我們看到all對應的dependency是file_file_with_nonsense,就去找file_file_with_nonsense的生成語句,發現它的dependency是create_file,然後去找create_file的生成語句,就到touch silly_file,touch是Unix中的典型命令,用於生成空的文件。create_file的語句執行完之後,回到file_file_with_nonsense,執行echo "Hello, there is nothing important here" > silly_file,就把"Hello, there is nothing important here" 寫入silly_file中,file_file_with_nonsense的語句也執行完之後,我們就返回到all,然後在命令行輸出"I have mostly created a lot of junk today!"。
因為其他的target,不在all的dependency list中,也不在all的dependency的dependency當中,所以只能通過make target的形式來調用對應的命令。
Marvelous macros(宏)
一個宏的示例,宏就是Makefile中的variables,用來定義我們需要的操作,一些變數之類的
CXX = clang++
FLAGS = -O
hello : hello_world.cpp
$(CXX) $(FLAGS) $? -o $@
clean :
rm hello
CXX,這是一個預定義的宏,default value是g++。這里把CXX定義成clang++了。
FLAGS,這里定義的是-O。FLAGS也不一定非得定義成-o,也可以是some moose have large antlers,但是這樣定義的話,就會導致調用的時候出錯。
對於上面的文件,我們在命令行輸入make的時候,實際運行的是clang++ -O hello_world.cpp -o hello。
如果我們把CXX=clang++這一行刪掉的話,在命令行輸入make,實際運行的就是g++ -O hello_world.cpp -o hello。
定義好macro宏,我們使用的時候,就要用$(MACRO)這樣的形式,這是makefile語言的一種語法。我們注意到MACRO全部用的大寫,雖然不是明確規定的,但是通常情況下用大寫。
$?和$@是makefile language裡面特別的預定義的宏。$?是指的"names of the dependencies(newer than the target)",$@是指的"name of the target"。
Complier and liner flags in CS 225
CXX = clang++ LD = clang++
CXXFLAGS = -std=c++1y -stdlib=libc++ -c -g -O0 -Wall -Wextra -Werror -pedantic
LDFLAGS = -std=c++1y -stdlib=libc++ -lpng -lc++abi
② 如何自己編寫Makefile
相信很多朋友都有過這樣的經歷,看著開源項目中好幾頁的makefile文件,不知所雲。在日常學習和工作中,也有意無意的去迴避makefile,能改就不寫,能用ide就用ide。其實makefile並沒有想像的那麼難寫,只要你明白了其中的原理,自己實踐幾次。你也可以自己寫makefile,讓別人對你頭來羨慕的目光。
下面本人介紹一下自己的學習成果,初學階段,歡迎大家多多指正。
簡單的說,makefile定義了一系列的規則來指定,哪些文件需要先編譯,哪些文件需要後編譯,哪些文件需要重新編譯,甚至可以在makefile中執行shell腳本。makefile帶來的好處就是——「自動化編譯」,一旦寫好,只需要一個make命令,整個工程完全自動編譯,極大的提高了軟體開發的效率。
關於程序的編譯和鏈接
一般來說,無論是C還是C++,首先要把源文件編譯成中間代碼文件,在Windows下也就是 .obj 文件,UNIX下是 .o
文件,即 Object File,這個動作叫做編譯(compile),一般來說,每個源文件都應該對應於一個中間目標文件(O文件或是OBJ文件)。然後再把大量的Object
File合成執行文件,這個動作叫作鏈接(link)。
編譯時,編譯器需要的是語法的正確,函數與變數的聲明的正確。對於後者,通常是你需要告訴編譯器頭文件的所在位置(頭文件中應該只是聲明,而定義應該放在C/C++文件中),只要所有的語法正確,編譯器就可以編譯出中間目標文件。
鏈接時,主要是鏈接函數和全局變數,所以,我們可以使用這些中間目標文件(O文件或是OBJ文件)來鏈接我們的應用程序。鏈接器並不管函數所在的源文件,只管函數的中間目標文件(Object
File),在大多數時候,由於源文件太多,編譯生成的中間目標文件太多,而在鏈接時需要明顯地指出中間目標文件名,這對於編譯很不方便,所以,我們要給中間目標文件打個包,在Windows下這種包叫「庫文件」(Library
File),也就是 .lib 文件,在UNIX下,是Archive File,也就是 .a 文件。
下面我們開始看看如何自己寫出makefile。
Makefile的規則
目標 :
需要的條件 (注意冒號兩邊有空格)
命令(注意前面用tab鍵開頭)
解釋一下:
1
目標可以是一個或多個,可以是Object File,也可以是執行文件,甚至可以是一個標簽。
2
需要的條件就是生成目標所需要的文件或目標
3
命令就是生成目標所需要執行的腳本
總結一下,就是說一條makefile規則規定了編譯的依賴關系,也就是目標文件依賴於條件,生成規則用命令來描述。在編譯時,如果需要的條件的文件比目標更新的話,就會執行生成命令來更新目標。
下面舉個簡單的例子說明。如果一個工程有3個頭文件,和8個C文件,我們為了完成前面所述的那三個規則,我們的Makefile應該是下面的這個樣子的。
edit : main.o kbd.o command.o display.o
/
insert.o search.o files.o utils.o
cc -o edit
main.o kbd.o command.o display.o /
insert.o search.o
files.o utils.o
main.o : main.c
defs.h
cc -c main.c
kbd.o : kbd.c defs.h
command.h
cc -c kbd.c
command.o : command.c defs.h
command.h
cc -c command.c
display.o : display.c defs.h
buffer.h
cc -c display.c
insert.o : insert.c defs.h
buffer.h
cc -c insert.c
search.o : search.c defs.h
buffer.h
cc -c search.c
files.o : files.c defs.h buffer.h
command.h
cc -c files.c
utils.o : utils.c
defs.h
cc -c utils.c
clean :
rm edit main.o
kbd.o command.o display.o /
insert.o search.o files.o
utils.o
將上面的內容寫入到Makefile文件中,然後執行make就可以進行編譯,執行make
clean就可以刪除所有目標文件。解釋一下,也就是說生成最終的目標文件edit,依賴於一系列的.o目標文件,而這些.o文件又是需要用源文件來編譯生成的。
需要注意的是,clean後面沒有條件,而clean本身也不是文件,它只不過是一個動作名字,其冒號後什麼也沒有,那麼,make就不會自動去找文件的依賴性,也就不會自動執行其後所定義的命令。
make是如何工作的
在默認的方式下,也就是我們只輸入make命令。那麼,
1、make會在當前目錄下找名字叫「Makefile」或「makefile」的文件。
2、如果找到,它會找文件中的第一個目標文件(target),在上面的例子中,他會找到「edit」這個文件,並把這個文件作為最終的目標文件。
3、如果edit文件不存在,或是edit所依賴的後面的 .o
文件的文件修改時間要比edit這個文件新,那麼,他就會執行後面所定義的命令來生成edit這個文件。
4、如果edit所依賴的.o文件也不存在,那麼make會在當前文件中找目標為.o文件的依賴性,如果找到則再根據那一個規則生成.o文件。(這有點像一個堆棧的過程)
5、當然,你的C文件和H文件是存在的啦,於是make會生成 .o 文件,然後再用 .o
文件生命make的終極任務,也就是執行文件edit了。
makefile中使用變數
前面的知識已經足以讓你自己完成一個簡單的makefile了,不過makefile的精妙之處遠不止如此,下面來看看如何在makefile中使用變數吧。
在上面的例子中,先讓我們看看edit的規則:
edit : main.o kbd.o command.o
display.o /
insert.o search.o files.o
utils.o
cc -o edit main.o kbd.o command.o display.o
/
insert.o search.o files.o utils.o
我們可以看到[.o]文件的字元串被重復了兩次,如果我們的工程需要加入一個新的[.o]文件,那麼我們需要在兩個地方加(應該是三個地方,還有一個地方在clean中)。當然,我們的makefile並不復雜,所以在兩個地方加也不累,但如果
makefile變得復雜,那麼我們就有可能會忘掉一個需要加入的地方,而導致編譯失敗。所以,為了makefile的易維護,在makefile中我們可以使用變數。makefile的變數也就是一個字元串,理解成C語言中的宏可能會更好。
於是,我們使用變數objects
objects = main.o kbd.o command.o display.o
/
insert.o search.o files.o utils.o
這樣一來,原來的makefile變成如下的樣子:
objects = main.o kbd.o command.o display.o
/
insert.o search.o files.o utils.o
edit : $(objects)
cc -o edit $(objects)
main.o : main.c defs.h
cc -c
main.c
kbd.o : kbd.c defs.h command.h
cc -c kbd.c
command.o : command.c defs.h command.h
cc -c command.c
display.o : display.c defs.h buffer.h
cc -c display.c
insert.o : insert.c defs.h buffer.h
cc -c insert.c
search.o : search.c defs.h buffer.h
cc -c search.c
files.o
: files.c defs.h buffer.h command.h
cc -c files.c
utils.o
: utils.c defs.h
cc -c utils.c
clean :
rm
edit $(objects)
這樣看起來方便多了吧,也更加省事了。如果有新的.o文件怎麼辦?當然是在objects裡面添加了,這樣只需要一處改變,很方便吧。
讓make自動推導
GNU的make很強大,它可以自動推導文件以及文件依賴關系後面的命令,於是我們就沒必要去在每一個[.o]文件後都寫上類似的命令,因為,我們的make會自動識別,並自己推導命令。
只要make看到一個[.o]文件,它就會自動的把[.c]文件加在依賴關系中,如果make找到一個whatever.o,那麼whatever.c,就會是whatever.o的依賴文件。並且
cc -c whatever.c
也會被推導出來,於是,我們的makefile再也不用寫得這么復雜。我們的是新的makefile又出爐了。
objects = main.o kbd.o command.o display.o
/
insert.o search.o files.o utils.o
edit : $(objects)
cc -o edit $(objects)
main.o : defs.h
kbd.o :
defs.h command.h
command.o : defs.h command.h
display.o : defs.h
buffer.h
insert.o : defs.h buffer.h
search.o : defs.h
buffer.h
files.o : defs.h buffer.h command.h
utils.o :
defs.h
clean :
rm edit
$(objects)
當然,如果你覺得那麼多[.o]和[.h]的依賴有點不爽的話,好吧,沒有問題,這個對於make來說很容易,誰叫它提供了自動推導命令和文件的功能呢?來看看最新風格的makefile吧。
objects = main.o kbd.o command.o display.o
/
insert.o search.o files.o utils.o
edit : $(objects)
cc -o edit $(objects)
$(objects) : defs.h
kbd.o
command.o files.o : command.h
display.o insert.o search.o files.o :
buffer.h
clean :
rm edit $(objects)
③ makeFile文件作用是什麼
其作用如下:
makefile關繫到了整個工程的編譯規則。一個工程中的源文件不計數,其按類型、功能、模塊分別放在若干個目錄中,makefile定義了一系列的規則來指定,哪些文件需要先編譯,哪些文件需要後編譯,哪些文件需要重新編譯,甚至於進行更復雜的功能操作,因為makefile就像一個Shell腳本一樣,其中也可以執行操作系統的命令。
makefile帶來的好處就是——「自動化編譯」,一旦寫好,只需要一個make命令,整個工程完全自動編譯,極大的提高了軟體開發的效率
記得要贊一個哦
④ Makefile.am 規則和實例詳解
編寫linux C 程序的時候,自己來寫Makefile著實的讓人很頭疼,如果是簡單的項目自己寫寫也就罷了,但是如果遇到大項目自己寫Makefile,那是要弄死人的,所以最近在研究Autotools工具自動生成Makefile,在用到autotools工具生成Makefile的時候,還是有一部分需要自己來完成的,那就是Makefile.am文件。
項目中寫在源文件里的Makefile.am是一種比我們了解的Makefile更高層次的編譯規則,它可以和編寫的configure.in(了解更多configure.in的規則請閱讀《 configure.ac (configure.in)詳解 》)文件一起通過調用automake命令,來生成Makefile.in文件,然後再調用./configure,將Makefile.in文件自動的生成Makefile文件。所以Makefile.am文件是要自動生成Makefile必不可少的元素,下面鵬博客就來和大家著重的學習下Makefile.am的寫法和規則。
先來說下Makefile.am中常見的文件編譯類型,詳細的編譯類型和全局變數鵬博客會在下面在圖表中列出:
PROGRAMS 表示可執行文件
SOURCES 表示源文件
HEADERS 頭文件。
LIBRARIES 表示庫文件
LTLIBRARIES 這也是表示庫文件,前面的LT表示libtool。
DATA 數據文件,不能執行。
SCRIPTS 腳本文件,這個可以被用於執行。如:example_SCRIPTS,如果用這樣的話,需要我們自己定義安裝目錄下的example目錄,很容易的,往下看。
一、基本寫法
下面就直接引入一個例子進行詳細講解,如下:
AUTOMAKE_OPTIONS = foreign
bin_PROGRAMS = client
client_SOURCES = key.c connect.c client.c main.c session.c hash.c
client_CPPFLAGS = -DCONFIG_DIR=\「$(sysconfdir)\」 -DLIBRARY_DIR=\」$(pkglibdir)\」
client_LDFLAGS = -export-dynamic -lmemcached
noinst_HEADERS = client.h
INCLUDES = -I/usr/local/libmemcached/include/
client_LDADD = $(top_builddir)/sx/libsession.la \
$(top_builddir)/util/libutil.la
上面就是一個Makefile.am示例文件,這個文件是用於生成client可執行應用程序,引用了兩個靜態庫和MC等動態庫的連接。
先來看個圖表一(列出了可執行文件、靜態庫、頭文件和數據文件,四種書寫Makefile.am文件個一般格式。):
對於可執行文件和靜態庫類型,如果只想編譯,不想安裝到系統中,可以用noinst_PROGRAMS代替bin_PROGRAMS,noinst_LIBRARIES代替lib_LIBRARIES。以此類推。
根據這個圖表一來分析下具體內容:
AUTOMAKE_OPTIONS :這個是用來設定automake的選項。automake主要是幫助開發GNU軟體的人員維護軟體套件,一般在執行automake時會檢查目錄下是否存在標准GNU套件中應具備的文件檔案,例如NEWS、AUTHOR、ChangeLog等,設成foreign時,automake會改用一般軟體套件標准來檢查,而gnu是預設設置,該級別下將盡可能地檢查包是否服從GNU標准,gnits是嚴格標准,不推薦。
bin_PROGRAMS :表示要生成的可執行應用程序文件,這里的bin表示可執行文件在安裝時需要被安裝到系統中,如果只是想編譯。不想被安裝到系統中,可以用noinst_PROGRAMS來代替。
那麼整個第一行 bin_PROGRAMS=client 詳細表示什麼意思那,解釋如下:
PROGRAMS知道這是一個可執行文件。
client表示編譯的目標文件。
bin表示目錄文件被安裝到系統的目錄。
如程序和圖片所示,包括頭文件,靜態庫的定義等等都是這種形式,如lib_LIBRARIES=util,表示將util庫安裝到lib目錄下。
繼續解釋文件內容:
client_SOURCES :表示生成可執行應用程序所用的所有源文件源文件,多個就空格隔開,我們注意到client_是由前面的bin_PROGRAMS指定的,如果前面是生成example, 那麼這里也就變成example_SOURCES,其它的規則類似標識也是一樣。
client_CPPFLAGS :這個和我們寫Makefile的時候意思是一樣的,都表示C語言的預處理器參數,這里指定了DCONFIG_DIR,以後在程序中,就可以直接使用CONFIG_DIR,不要把這個和另一個CFLAGS混淆,後者表示編譯器參數。
client_LDFLAGS :表示在連接時所需要的庫文件選項標識。這個也就是對應一些如-l,-shared等選項。
noinst_HEADERS :表示該頭文件只是參加可執行文件的編譯,而不用安裝到安裝目錄下。如果需要安裝到系統中,可以用include_HEADERS來代替。
INCLUDES :表示連接時所需要的頭文件。
client_LDADD :表示連接時所需要的庫文件,這里表示需要兩個庫文件的支持,下面會看到這個庫文件又是怎麼用Makefile.am文件後成的。
如圖表二:
全局變數 ,可能有人注意到文件中的$(top_builddir)等全局變數,其實這個是Makefile.am系統定義的一個基本路徑變數,表示生成目標文件的最上層目錄,如果這個Makefile.am文件變成其它的Makefile.am文件,那麼這個就表示其它的目錄,而不是這個當前目錄。我們還可以使用$(top_srcdir),這個表示工程的最頂層目錄,其實也是第一個Makefile.am的入口目錄,因為Makefile.am文件可以被遞歸性的調用。
如圖表三:(在Makefile.am中盡量使用相對路徑,系統預定義了兩個基本路徑)
$(sysconfdir) :在系統安裝工具的時候,我們經常能遇到配置安裝路徑的命令,如:./configure –prefix=/install/apache 其實在調用這個之後,就定義了一個變數$(prefix), 表示安裝的路徑,如果沒有指定安裝的路徑,會被安裝到默認的路徑,一般都是/usr/local。在定義$(prefix),還有一些預定義好的目錄,其實這一些定義都可以在頂層的Makefile文件中可以看到,如下面一些值:
bindir = $(prefix)/bin。
libdir = $(prefix)/lib。
datadir=$(prefix)/share。
sysconfdir=$(prefix)/etc。
includedir=$(prefix)/include。
這些量還可以用於定義其它目錄,例如我想 將client.h安裝到include/client目錄下 ,這樣寫Makefile.am文件:
clientincludedir=$(includedir)/client
clientinclude_HEADERS=$(top_srcdir)/client/client.h
這就達到了我的目的,相當於定義了一個安裝類型,這種安裝類型是將文件安裝到include/client目錄下。
我們自己也可以 定義新的安裝目錄下的路徑 ,如我在應用中簡單定義的:
devicedir = ${prefix}/device
device_DATA = package
這樣的話,package文件會作為數據文件安裝到device目錄之下,這樣一個可執行文件就定義好了。注意,這也相當於定義了一種安裝類型:devicedir,所以你想怎麼安裝就怎麼安裝,後面的XXXXXdir,dir是固定不變的。
二、配置靜態庫
下面我們來說下編譯靜態庫和編譯動態庫,我們說下靜態庫,下面這個例子比較簡單。直接指定 XXXX_LTLIBRARIES或者XXXX_LIBRARIES就可以了。同樣如果不需要安裝到系統,將XXXX換成noinst就可以。
一般推薦使用libtool庫編譯目標,因為automake包含libtool,這對於跨平台可移植的庫來說,是一個很好的事情。
看例子如下:
noinst_LTLIBRARIES = libutil.la
oinst_HEADERS = inaddr.h util.h compat.h pool.h xhash.h url.h device.h
ibutil_la_SOURCES = access.c config.c datetime.c hex.c inaddr.c log.c device.c pool.c rate.c sha1.c stanza.c str.c xhash.c
ibutil_la_LIBADD = @LDFLAGS@
第一行的noinst_LTLIBRARIES,這里要注意的是LTLIBRARIES,另外還有LIBRARIES,兩個都表示庫文件。前者表示libtool庫,用法上基本是一樣的。如果需要安裝到系統中的話,用lib_LTLIBRARIES。
.la 為libtool自動生成的一些共享庫,vi編輯查看,主要記錄了一些配置信息。可以用如下命令查看*.la文件的格式 $file *.la
.a 為靜態庫,是好多個.o合在一起,用於靜態連接
如果想編譯 .a 文件,那麼上面的配置就改成如下結果:
noinst_LTLIBRARIES = libutil.a
oinst_HEADERS = inaddr.h util.h compat.h pool.h xhash.h url.h device.h
ibutil_a_SOURCES = access.c config.c datetime.c hex.c inaddr.c log.c device.c pool.c rate.c sha1.c stanza.c str.c xhash.c
ibutil_a_LIBADD = @LDFLAGS@
注意:靜態庫編譯連接時需要其它的庫的話,採用XXXX_LIBADD選項,而不是前面的XXXX_LDADD。編譯靜態庫是比較簡單的,因為直接可以指定其類型。
三、配置動態庫
如果想要編譯XXX.so動態庫文件,需要用到_PROGRAMS類型,有一個關於安裝路徑的問題,如果希望將動態庫安裝到lib目錄下,按照前面所說的,只需要寫成lib_PROGRAMS就可以了,lib表示安裝的路徑,但是automake不允許這樣直接定義,所以可以採用下面的辦法,同樣是將動態庫安裝到lib目錄下:
projectlibdir=$(libdir)//新建一個目錄,就是該目錄就是lib目錄
projectlib_PROGRAMS=project.so
project_so_SOURCES=xxx.C
project_so_LDFLAGS=-shared -fpic//GCC編譯動態庫的選項
這個動態庫的編譯寫法是鵬博客網上總結的,希望有要的人自己來驗證下。
四、SUBDIRS功能用法
SUBDIRS 這是一個很重要的詞,我們前面生成了一個目標文件,但是一個大型的工程項目是由許多個可執行文件和庫文件組成,也就是包含多個目錄,每個目錄下都有用於生成該目錄下的目標文件的Makefile.am文件,但頂層目錄是如何調用,才能使下面各個目錄分別生成自己的目標文件呢?就是SUBDIRS關鍵詞的用法了。
看一下我的工程項目,這是頂層的Makefile.am文件
EXTRA_DIST = Doxyfile.in README.win32 README.protocol contrib UPGRADE
devicedir = ${prefix}/device
device_DATA = package
SUBDIRS = etc man
ifUSE_LIBSUBST
SUBDIRS += subst
endif
SUBDIRS += tools io sessions util client dispatch server hash storage sms
SUBDIRS表示在處理目錄之前,要遞歸處理哪些子目錄,要注意處理的順序。比如配置中的client對sessions和utils這兩上目標文件有依賴關系,就在client之前需要處理這兩個目標文件。
EXTRA_DIST :將哪些文件一起打包。
五、打包處理
Automake會自動的打包 ,自動打包的內容如下:
所有程序的源文件。
所有子目錄里的的Makefile.am文件。
Makefile.am中包含的文件。
./configure所要讀取的文件。
EXTRA_DIST所指定的文件。
dist和nodist指定的文件,也可將其中一個源文件指定為不打包:
例如: nodist_client_SOURCES = client.c
六、最後
這里是鵬博客總結的一些比較實用的Makefile.am的寫法和規則,看完了這篇文章已經可以很詳細的理解這個文件的內容,寫起來也應該不會陌生,但automake還有許多其他的規則需要掌握,鵬博客將會繼續全面的總結關於autotools 的一些規則和寫法,希望對大家有用處。也歡迎大家指出問題,幫我完善這個博客,希望大家支持!
automake的Makefile.am Makefile.am寫法
⑤ linux如何編寫並使用makefile
1、先寫Makefile編譯出***.ko文件
模板如下,保存到命名為Makefile文件里,放到你代碼的同級目錄下
TARGET=my_proc.ko
LINUXDIR=/lib/moles/$(shell uname -r)/build
PWD=$(shell pwd)
obj-m :=
obj-m += my_proc.o
all: $(TARGET)
$(TARGET): $(OBJS)
make -C $(LINUXDIR) SUBDIRS=$(PWD) moles
clean:
rm -f moles.order Mole.symvers $(TARGET) *.mod.c *.o
rm -rf .tmp_versions .mod* Mole.markers
2、make
3、root許可權下用命令插入模塊
insmod my_proc.ko
4、可以用你寫的應用程序打開、操作模塊了
5、查看模塊命令
lsmod
cat /proc/moles
modinfo my_proc.ko
6、root下卸載模塊
rmmod
⑥ 在VC里如何用Makefile文件編譯
運行cmd.exe (or command.com in win9x)->進到vc/bin目錄->運行vc-vars32.bat->進到makefile 所在的目錄->nmake /f makefile
從sourceforge上下載下來的libjpeg源代碼中有一個makefile.vc的文件,可以通過nmake /f makefile.vc [nodebug=1]來編譯libjpeg,但是只能編譯靜態庫,如果需要編譯dll以便在emacs等程序中使用的話,需要修改makefile.vc和jmorecfg.h文件。在makefile.vc文件中添加編譯dll規則:
以下內容為程序代碼:
libjpeg.lib: $(LIBOBJECTS) $(RM) libjpeg.lib lib -out:libjpeg.lib $(LIBOBJECTS) #
添加以下這行 libjpeg.dll: $(LIBOBJECTS) $(RM) libjpeg.dll link -dll -out:libjpeg.dll $(LIBOBJECTS) 在jmorecfg.h中添加#define _WIN32_#define JPEG_DLL 然後nmake /f makefile.vc nodebug=1就可以編譯了。
將makefile復制為一個.mak文件,然後用VC打開即可!
.mak 就是一個makefile
可以指定怎樣編譯(命令行,必須先設置VC命令行環境)
vcvars32.bat可設置環境,在vc98/bin下 nmake /f XXXX.mak
如果有一個makefile就只要nmake就可以了。
⑦ Makefile詳解
make 命令執行時,需要根據一些規則來決定按照怎麼樣的方式去 編譯和鏈接程序 ,這些規則就由 makefile 文件所指定。如果我們 makefile 文件寫的足夠好,make 命令會自動地根據當前的文件修改的情況來確定哪些文件需要重編譯,從而自己編譯所需要的文件和鏈接目標程序。
首先,本文將給出一個makefile文件的示例,以便大家能有一個直觀感受,這個例子來源於 GNU的make使用手冊 。在這個例子中,我們的工程有8個c文件,和3個頭文件,我們要寫一個makefile來告訴make命令如何編譯和鏈接這幾個文件。例子如下:
這個例子里 make 的編碼規則如下:
a. 如果這個工程沒有編譯過,那麼我們的所有c文件都要編譯並被鏈接。
b. 如果這個工程的某幾個c文件被修改,那麼我們只編譯被修改的c文件,並鏈接目標程序。
c. 如果這個工程的頭文件被改變了,那麼我們需要編譯引用了這幾個頭文件的c文件,並鏈接目標程序。
在詳細拆解上一節的 Makefile 之前,先來看下 Makefile 的基本範式。
target可以是一個 1) object file(可執行文件) ,2) 可執行文件 ,還可以是個3) label(標簽) ,關於標簽這個特性,在後面的 偽目標 章節還會有敘述。
prerequisites 就是,要生成那個target所需要的文件或是目標。 command 也就是 make 需要執行的命令,可以是任意的
shell 命令。
這是一個文件的依賴關系,也就是說,target 這一個或多個的目標文件依賴於 prerequisites 中的文件,其生成規則定義在 command 中。同時, prerequisites 中如果有一個以上的文件比target文件要新的話, command 所定義的命令就會被執行。這就是 Makefile 的規則,也是 Makefile 中 最核心 的內容。
有了這些規則後,再來分析上面的例子。在這個 makefile 中,目標文件(target)包含:
依賴文件(prerequisites)就是冒號後面的那些 .c 文件和 .h 文件。每一個 .o 文件都有一組依賴文件,而這些 .o 文件又是執行文件 edit 的依賴文件。
在定義好依賴關系後,後續的那一行定義了如何生成目標文件的系統命令, 一定要以一個tab鍵作為開頭 。 make 會比較
targets 文件和 prerequisites 文件的修改日期,如果 prerequisites 文件的日期要比targets文件的日期要新,或者 target 不存在的話,那麼,make就會執行後續定義的命令。
我們可以把這個內容保存在名字為 makefile 或 Makefile 的文件中,然後在該目錄下直接輸入命令 make 就可以生成可執行文件edit。如果要刪除執行文件和所有的中間目標文件,那麼,只要簡單地執行一下 make clean 就可以了。 註:反斜線()是換行符的意思,這樣比較便於閱讀。
這里要說明一點的是, clean 不是一個文件,它只不過是一個動作名字,有點像C語言中的 lable 一樣,其冒號後什麼也沒有,那麼,make就不會去找它的依賴性,也就不會自動執行其後所定義的命令。要執行其後的命令(不僅用於 clean,其他 lable 同樣適用),就要在 make 命令後顯式指出這個 lable 的名字。這樣的方法非常有用, 我們可以在一個 makefile 中定義不用的編譯或是和編譯無關的命令,比如程序的打包,程序的備份 ,等等。
在默認的方式下,也就是我們只輸入make命令。那麼,
這就是整個 make 的依賴性,make 會一層又一層地去找文件的依賴關系,直到最終編譯出第一個目標文件。在找尋的過程中,如果出現錯誤,比如最後被依賴的文件找不到,那麼make就會直接退出,並報錯,而對於所定義的命令的錯誤,或是編譯不成功,這些都不在 make 職責范圍內。
通過上述分析,我們知道,像 clean 這種,沒有被第一個目標文件直接或間接關聯,那麼它後面所定義的命令將不會被自動執行,不過,我們可以顯示要 make 執行。即命令 make clean ,以此來清除所有的目標文件,以便重編譯。
在上面的例子中可以看到,後綴為 .o 的一大串文件名寫了兩次,這樣比較費時費力,而且如果文件有所增減,要修改的地方也非常多,對以後的維護造成困難。在這種情形下,我們可以在Makefile里使用變數代替這一大串依賴文件,這里變數的使用方式基本類似於shell腳本里變數的使用方法。
我們可以在makefile一開始就這樣定義:
那麼接下來我們就可以很方便地在我們的Makefile中以 $(objects) 的方式來使用這個變數了,於是如果有新的 .o 文件加入,我們只需簡單地修改一下 objects 變數就可以了。
GNU 的 make 很強大,它可以自動推導文件以及文件依賴關系後面的命令,於是我們就沒必要去在每一個 .o 文件後都寫上類似的命令。因為,我們的make會自動識別,並自己推導命令。
只要make看到一個 .o 文件,它就會自動的把 .c 文件加在依賴關系中,如果make找到一個 FILENAME.o ,那麼 FILENAME.c ,就會是 FILENAME.o 的依賴文件。並且 cc -c FILENAME.c 也會被推導出來,於是,我們的makefile 再也不用寫得這么復雜。我們的新makefile就可以這么寫了。
這種方法,也就是make的**。上面文件內容中,「.PHONY」表示,clean是個偽目標文件。
⑧ makefile文件的作用是什麼
其作用如下:
makefile關繫到了整個工程的編譯規則。一個工程中的源文件不計數,其按類型、功能、模塊分別放在若干個目錄中,makefile定義了一系列的規則來指定,哪些文件需要先編譯,哪些文件需要後編譯,哪些文件需要重新編譯,甚至於進行更復雜的功能操作,因為makefile就像一個shell腳本一樣,其中也可以執行操作系統的命令。
makefile帶來的好處就是——「自動化編譯」,一旦寫好,只需要一個make命令,整個工程完全自動編譯,極大的提高了軟體開發的效率
記得要贊一個哦