關於linux編譯檔案的一些感想

近段時間，博主一直在學習gcc編譯以及make的一些知識，有一些小的感想分享一下。

我們在編譯檔案的時候一直採用的是

//假設我們有 1.h  1.cpp   2.h   2.cpp  main.cpp

我們編譯經常是 
g++ -c 1.cpp
g++ -c 2.cpp
g++ -c main.cpp
g++ -o 1.o 2.o main.o -o main.out

g++ 1.cpp 2.cpp main.cpp -o main.out

1、這樣不會有中間檔案輸出

2、一旦編譯出錯，整個專案的所有檔案都需要重新編譯。檔案編譯花費的時間不長還好，如果需要花費很長的時間，那麼對於開發人員來說將是大大降低工作效率的存在（這裡也可以檢視vs的編譯過程，它會將已經編譯過的檔案寫成obj檔案，然後如果你沒有改過原始檔，vs是不會再去編譯這個檔案的，只是鏈結的時候會把這些中間檔案鏈結成乙個exe程式）

ps：我在用centos7 進行g++的時候，會出現這麼個錯誤

g++: command not found

yum -y update gcc

yum -y install gcc+ gcc-c++
親測，源於：

Linux的編譯檔案操作

檔案程式設計的內容很多，但是重點在應用，主要關心如何用 操作檔案，實現檔案建立，開啟，編輯等自動化執行。開啟 open 讀寫 write read 游標定位 lseek 關閉 close int close int fd 引數說明 fd 是需要關閉的檔案描述符 標頭檔案 include 原型 ssi...

關於編譯opencv contrib的一些總結

首先說下我的程式設計環境 win10 64 位 vs2017 opencv3.3.1dubug opencv2.4.9 提到opencv2.4.9的原因 opencv2.4.9為十分經典的版本，如果在多次編譯opencv contrib未果的情況下，不妨可以退回到opencv2.4.9，實測在上述環...

關於編譯的一些感觸

今天因為需求去編譯qt5的時候遇到錯誤 nmake fatal error u1077 cd 返回 0x2 以前編譯opencv的時候也遇到很多編譯錯誤 我說一下感觸 第一 不要帶中文路徑 第二 路徑不要帶空格，比如這種program files x86 第三 也是今天遇到的，路徑不要太長，太長也會...