?1. make / Makefile 自動化構建的工具
1）引入
在我們進行一些大型的工程的時候，代碼量是極其大，當我們代碼在進行一系列的編譯的時候，難免會出現一些錯誤，當我們對錯誤進行一系列的更改之后，難道我們需要再重新敲剛剛一系列的相關指令嗎？？ 假設我們有上百個源代碼，每一個都需要重新敲入相關的指令嗎？？ 這難免比較耗時。那有沒有一些工具，可以進行對文件的相關編譯原則，我們只需要輸入指定的簡短的指令，來完成對上百個源代碼的編譯。
make/Makefile 就是一個解決上述問題的自動化工具。
make：是一條指令。
Makefile: 是一個包含一系列編譯原則的文件。通過調用make? 指令來完成指定文件的編譯。他用
于告訴 make 程序如何編譯和鏈接一個程序。它包含了目標（target）、依賴關系
（dependencies）、命令（commands）等內容，使得我們可以通過簡單的命令來構建和管理復雜
的軟件項目。
2）使用
I)首先創建一個 makefile / Makefile 文件
touch makefile/MakefileII) Makefile? 里面的內容：存放依賴的 關系以及依賴方法
對指定文件進行預編譯，編譯，匯編，鏈接對應的指令 ，這里不再一一贅述，可見上篇博客文件編譯對應的指定指令
III）在命令提示符里面直接使用meke 指令，就可以自動化完成指定文件的 編譯。?
?注意：make 指令會自動推導對應的依賴關系，他的推導過程是一種棧式推導的；
一旦生成對應的第一個目標文件，此時就會停下來，其他 的對應目標文件不會生成，在默認的情
況下。也可以使用 make? + 指定的目標文件?
?3）相關問題
I) 為什么多次進行 make? ?的時候，顯示以下的提示信息：該目標文件已經是最新的
分析：其實每次在進行 make 指令進行編譯的時候，通過對比目標文件與源文件之間的“新舊” 時間，來決定是否再次執行make 指令。
II) 為什么會這樣進行執行？？？
為了提高編譯的效率。
一般情況下：首次進行編譯的時候，目標文件是新于 源文件的，因為先有源文件，才有了對應的
目標文件（注意：這里的目標文件不僅僅指的是，匯編生成的目標文件，也可能是可執行文件或者
是預編譯，編譯生成對應的目標文件）。
當我們沒有對源文件進行相應的修改，此時源文件是老于 目標文件的，假設當前make? 指令會再
次生效，當源文件的體積很大時候，在進行編譯的時候，會消耗大量的時間，所以為了提高編譯
的效率，當源文件老于 目標文件的時候，不會再次執行make? 指令。
本質：看源文件的內容是否發生變化，來決定是否再次進行make 指令的執行
4）對上面 的問題進行驗證
編譯器是如何知道當前的源文件的時間是 老于，還是新于 目標文件的呢？？？
首先需要知道幾個時間：
access:記錄對文件訪問的時間
modify： 記錄對文件內容的修改時間
change:記錄對文件的屬性修改時間
I) 查看一個文件的訪問，修改，時間：stat
此時目標文件是新于 源文件的，所以當我們再次執行 make? 的時候初出現以下的現象：
當我們對源文件進行修改的時候（對文件的內容或者是文件的屬性進行修改），所見現象如下：
5）偽目標： .PHONY 的使用
當我們想 每次使用 make 的時候，都強制執行文件的編譯，此時可以使用偽目標 .PHONY
對要生成的目標文件進行 .PHONY? 偽目標的修飾
?但是一般不建議這樣寫，因為對于目標文件要是每次 make? 的時候，都進行編譯，這樣不僅僅會消耗時間還極其銷毀內存。但是對于文件的清理，可以使用 偽目標進行修飾。
2） make clean ：文件清理
使用：直接在命令提示符使用 make clean?
2. git?
1）git? 是什么
Git是一款免費、開源的分布式版本控制系統，用于敏捷高效地處理任何或小或大的項目。?
使用git 也可以進行團隊合作。
git? 的工作流程：
從遠程倉庫中克隆 Git 資源作為本地倉庫；
從本地倉庫中checkout代碼然后進行代碼修改；
在提交本地倉庫前先將代碼提交到暫存區；
提交修改，提交到本地倉庫；本地倉庫中保存修改的各個歷史版本；
在需要和團隊成員共享代碼時，可以將修改代碼push到遠程倉庫。
2）git? 的使用
I) 首先我們需要先創建一個遠程倉庫，具體實現細節見下：
?II） 把遠程倉庫拉取下來：先復制遠程倉庫的地址，具體實現細節見下
III）在命令行提示里面輸入一下指令：
IIII） git? 三板斧
git? add + 指定的文件
git? commit? -m? "關鍵 的文字說明"
git? ?push??:注意在這一步，會進行身份驗證，輸入git? 的賬號以及對應的密碼即可
以上只是對git? 的簡單介紹，感興趣的鐵汁們，可以自行資料的搜集
3 . gdb 調試器的使用
1）引入
眾所周知，Linux 是一個非圖形化界面的操作系統（也支持圖形化界面），在上面可以使用命令行的方式進行文件的創建，代碼的編寫，軟件的下載…… 但是當我們的代碼在進行運行的時候難免會遇到一些Bug ，此時又是如何調試的？？？
我們知道對于VS? 下，進行代碼的調試，有相關的按鍵支持，對于Linux 系統上，也是可以的，只不過這里是命令行的方式。
首先我們需要先下載 gdb 這個調試器。
sudo yum install -y gdbgdb 是一個開發環境必不可少的調試工具。
2） Debug 和 Release? 版本區別
當我們使用VS 進行代碼運行的時候，多數是在 Debug 版本下進行的，方面我們進行相關的調試
簡言之：Debug? 版本，進行程序的調試。
對于測試人員：當我們把寫好的項目進行終版的提交，他們會在 Release 版本下進行，主要
是發下各種問題，此時代碼里面是不包調試信息的，也就是用戶最終拿到的版本
3）Linux 下的gdb 相關的指令
I) 準備工作 ：編一個測試代碼
makefile? 文件的內容：
gcc? 默認進行文件編譯采用的是版本是Debug ,當我們指定進行Debug 版本進行相關信息的調試 的
時候對應 的指令：對可執行程序進行編譯的 時候，添加 -g? :進行debug? 版本編譯
?2）對指定程序進行調試? gdb + 可執行程序（注意這里 必須是可執行程序的文件）
如何判斷當前的可執行程序到底是Debug? 版本下生成的還是 Release? 版本生成的？？？
?通過比較對應生成文件的大小：因為Debug? 版本生成的文件，對應體積較大，因為需要包含一些
對應 的調試信息。
注意：gcc/g++ 編譯生成對應的文件默認是以 release 版本發布的；想對知道程序進行調試 的時
候，必須借助 Debug? 版本生成的程序：在編譯的時候指定? -g?
當我們進入gdb 模式下，我們是無法知道當前代碼的內容，此時可以借助? l 指令進行相關內容查找
?l + n? :查看當前代碼指定的多少行，一般方便我們進行相關斷點設置
l 0? ?和 l? 1 打印出來的內容是一樣的
當我們有了相關的內容，接下來就是如何進行打斷點
b +指定的行號（源代碼對應的某一行）
有了斷點的設置，接下來就是如何查看已經打的斷點？？？
info b
直接輸入? info 的時候，默認是把所有的調試信息打印出來，如今我們只需要知道當前的 斷點信息直接? info b
斷點的刪除：
d + 要刪除斷點對應的編號? 對指定端點的刪除
d breakpoints :刪除所有 的斷點
假設當前需要刪除代碼第7行對應的斷點，此時就需要找到當前斷點對應的編號： 3
程序的運行與調試：
r :遇到斷點會停下來，相當于VS下的 F5?
逐過程 和逐語句的調試：
n :逐過程的調試，一般用于對函數的調試，相當于VS 下的 F10
s: 逐語句的調試，一個語句一個語句的調試，相當于VS 下的F11
當我們進入函數內部，發現這個執行的過程比較長，并且也不是出發報錯的位置，想直接把
該函數運行完，返回調用該函數的位置：直接使用? finish? 指令即可
對變量的打印和追蹤：
p + 變量名 ： 顯示變量的值
display + 變量名 ： 每次運行完，都會打印一個當前變量對應的數值
對一個循環很長的代碼塊，此時一個一個指令的顯示比較麻煩，可以使用diaplsy 進行追蹤，此時
每執行一次循環，會自動打印變量的數值：
?當不需要對某個變量進行實時的跟蹤的時候，使用undislay? 進行設置。
?
以上是關于Linux 相關工具使用的簡單介紹，后期會不定期的進行內容法更新~~~
