Makefile 與 IDE 相比效率高在哪？

01-29

在學Linux開發，已經有幾個月的開發經歷。常聽一些有經驗的開發者說makefile在熟練之後效率比IDE(比如VS)效率高，體會不是很深刻，makefile的效率高在哪裡呢？
---------------------------------------------------------------------------------
今天編譯mysql的源碼，make過程中ctrl+c了，後來再編譯發現能在原來編譯的進度下繼續編譯。看了下文件似乎用的cmake，這樣的話cmake效率應該還是挺高的。

IDE 和 Makefile 並不是功能重複的兩個選擇。IDE 的「Integrated」有兩個意思，第一是把 coding，compiling，building，debugging 等功能集中到一個環境里。第二是代表它可以集成現有的工具，同時在這種 integration 中提供自己的功能。比如，可視化就是 IDE 的一種獨特功能，IDE 可以集成現有的 compiler 和 debugger，在之上它會提供 syntax highlight 和 debugging 的可視化功能。

Makefile 是傳統的 building 工具。和 coding，debugging 相比，building 對可視化的要求很低。從這個方面來說，很多 IDE 是可以直接調用 makefile 的。從這個角度說，IDE 和 makefile 沒有誰絕對替代誰的問題。

但是問題沒有這麼簡單。Makefile 是一種功能比較靈活的工具。而 IDE 為了實現一些功能，需要對整個 building 結構有充分的了解。所以從 IDE 的角度來說，直接集成 makefile 的所有功能可能會帶來一些麻煩。比如說 makefile 里如果做了直接修改某些 source file，或者創建 symbol link 的動作，IDE 的 debugging 可視化和函數定義查找等功能就會失敗。所以，出於「安全」的考慮，IDE 會設計一個比 makefile 靈活性小的多的 building 功能，保證整體的環境可用。

Makefile 的優勢在於，功能靈活，而且處理工具成熟穩定：

便於 version control。你說一萬遍「手寫 …… 已經過時了」，現實告訴你，只有手寫文件才能可靠的 version control。
任何 plain text editor 都能處理。還有很多諸如 grep，awk 之類的傳統工具。

與之相對的就是 IDE 的 project file 的劣勢。格式變化太大，就連 Visual Studio 和 Xcode 不同版本之間的 project file 都有很大變化。而且只能被一家 IDE 處理。

總之，你的程序離 UI 越近，你對 IDE 的整體調試開發功能要求越高，就越需要堅持使用 IDE 的 building 功能。

要是你能把IDE給用成一個makefile的圖形編輯器，那我算你屌。

===============================================

其實我還寫了一個Gay Make

源碼：Gac Library -- C++ Utilities for GPU Accelerated GUI and Script

輸入：

Gac Library -- C++ Utilities for GPU Accelerated GUI and Script

生成的makefile：

http://gac.codeplex.com/SourceControl/latest#Common/Linux/makefile

手寫 Makefile 已經過時。

唉，那些Makefile的人其實是無可奈何，你以為他們喜歡啊。

如果VS支持真正意義上的跨平台，誰tmd會找虐去Makefile。

目前VS的很多功能，其實就連自家Windows上，也沒做好，比如遠程調試。所以，Win+VS都有沒做好的地方，更何況Linux + 渣渣IDE環境。那些找不到IDE的，或者有Bug的，或者根本無法使用IDE的，沒辦法，才Makefile。

看上去會寫Makefile的人越來越少了，實際上一套簡單的Makefile就類似於一個庫，是很容易重用的。像OpenWRT的build系統這種過度使用Makefile的可能不多，但是像*BSD系統那樣提供一些常用模板是很常見的。

舉個例子，

# $FreeBSD$ # $NetBSD: Makefile,v 1.15 1997/10/18 15:31:20 lukem Exp $ # from: @(#)Makefile 8.2 (Berkeley) 4/3/94


.include &
# Uncomment the following to provide defaults for gate-ftp operation

#

#CFLAGS+=-DGATE_SERVER="ftp-gw.host" # -DGATE_PORT=21
TNFTP=	${.CURDIR}/../../contrib/tnftp

.PATH: ${TNFTP}/src
PROG=	ftp

SRCS=	cmds.c cmdtab.c complete.c domacro.c fetch.c ftp.c main.c

	progressbar.c ruserpass.c util.c
.if ${MK_INET6_SUPPORT} != "no"

CFLAGS+= -DINET6

.endif
CFLAGS+= -I${.CURDIR} -I${TNFTP}

LDADD=	-ledit -ltermcap -lutil

DPADD=	${LIBEDIT} ${LIBTERMCAP} ${LIBUTIL}
WARNS?=	2
LINKS=	${BINDIR}/ftp ${BINDIR}/pftp

	${BINDIR}/ftp ${BINDIR}/gate-ftp

MLINKS=	ftp.1 pftp.1

	ftp.1 gate-ftp.1

.include &

這是/usr/bin/ftp的Makefile，注意裡面的include，都是使用的現有的模板。至於autoconf那一套，在很多人眼中是只有不會寫Makefile的人才會用的。

一定是，可定製性

樓上諸位有點何不食肉糜了。

我一個CUDA程序，在Mac下開發，linux-sever下調試，運行在tegra tk1，我也想直接用ide啊（首先你需要一個不是eclipse改版的適合人類使用的cuda開發ide）。

沒辦法，選擇有二，手寫makefile或者cmake，於是我發現cmake+nvcc+clang的工具鏈在生成dynamic lib的時候在mac下有一個不大不小的bug折騰了我一晚上…最後改了cmake生成的link文件了事。

而且你們要知道，cuda在mac下默認是沒有arm-cross編譯功能的。當然你可以自己替換host compiler…但是這一切在ide（諸如clion xcode）設置起來簡直作死，尤其是xcode打開make工程都不給分析源碼。我還是cmake/make+vim+cscope吧

再有我們的無人機飛控系統基於pixhawk開發，這貨的操作系統是一個叫nuttx的傢伙……想用整套ide…先自己去織一套cross工具鏈吧。

當你還在打開IDE的時候，他已經make -j16了

可以試試cmake/qmake/qbs等等...

VS最好

Makefile 手寫路過，感覺非常簡單。Makefile 原則很簡單依賴什麼有沒有有就不管，沒有啊，那就有沒有生成步驟，推導到都有了就結束了。

makefile也可以寫的像好的代碼一樣，模塊化，可重用。

其實IDE在實現上也用的是makefile，只不過做了其他優化，使其更加方便。

學makefile確實幫助你理解編譯過程，更重要的是在linux下，很多時候你找不到合適的IDE，尤其是嵌入式軟體開發時。

可以試試 xmake 。。比起直接寫makefile 簡單多了。。而且跨平台。。基於Lua，靈活方便

VS 裡面集成了類似 make 的 nmake，VS作為集成開發環境，功能肯定是更多更方便的

開發效率大部分情況是 VS 比 makefile 高，因為用 VS 可以忽略很多無關的細節。

熟練了以後在小項目裡面其實也不太 care 寫不寫 makefile，因為通常情況下自己備有通用的模板，而且對規則也熟練了所以花不了多少時間。

看起來 VS 完勝，那麼VS 的缺點在哪？龐大，複雜，占內存！Makefile （或者說通過終端開發）小而美，很容易控制更多的細節，做更多的定製化，版本控制前面也提到了。

我在家裡一台用了七八年的機器ssh連上一個512M內存的虛擬機兩邊都跑的很歡。VS還是算了。。。而且有時候我就想寫個簡單的 demo，也許 VS 啟動的時間我已經在 VIM 裡面把代碼寫完了。極簡也是一種高效。

最後推銷一下自己寫的通用 Makefile ~ http://github.com/roxma/easymake ~ 媽媽再也不會擔心我不會寫 Makefile 了~

你去看本書吧，make gnu項目管理，雖然我還在看，感覺思想很好，只要自己有一個規範，後期項目重用一個就好，最近做一個wsn研究，遇到這樣一個問題，利用別人給你寫好makefile去向感測器結點燒程序時（make 會調東西），老是不能下載，開始考慮平台兼容問題，後來下了狠心，將整個makefile工程看了一邊，有些東西明顯是autotools做不了的，當然也可能是我的水平比較低，我前些階段，看了些autotools書，auto tools也有很多使用限制，好的make file可以將項目每一模塊功能部分分的清楚（當然你makefile水平要高），如果重新在這個軟體平台的話，項目可能就只是改改項目名，填幾個文件罷了，好吧，接著說我那個研究，很多使用這個實驗用的軟體系統的人，並不看make file，於是就提出各種方法，如果你真懂make file的，就是簡單的改改幾個文件的許可權就好，make file的語法有點怪，但真的很有學習價值

其實VS用的也是make，不過微軟的make叫做nmake，如果你看過他的makefile會發現跟gnu的makefile很像，而實際上這東西都是從gnu的抄過來的啊。

效率高不高關鍵看makefile寫的好不好，gnu的makefile寫好了可以進行差量編譯，並行編譯。修改哪個編哪個。不僅速度快，計算資源還少。

VS的話，其實也能實現，最終實現的都是用的make。效率高不高，現在來看編譯器似乎占的比重更大些，尤其是c++編譯器，差距很大。

有多少大項目是手寫makefile的。。單純手寫makefile去建一個 build system只能說他厲害了。。。OpenCV用的是cmake，在Linux上會自動生成makefile。Android有自己的Android.mk，而Android.mk本身就很像BSD make或者叫pmake。

你可以自己玩玩cmake，感受一下不同。

我開始做後台開發的的時候就覺得Linux的shell編程和makefile就是兩大傻，人生苦短啊，然後就去找了他們的替代品Python和cmake，後來被人問說不寫makefile不知道編譯連接的過程，我就呵呵了，之前我已經做客戶端編程幾年，vs編譯輸出窗口裡面，過程寫清清楚楚

用cmake,用xcode做ide