CLion是一款專為開發C及C++所設計的跨平臺IDE。它是以IntelliJ為基礎設計的，包含了許多智能功能來提高開發人員的生產力。這種強大的IDE幫助開發人員在Linux、OS X和Windows上來開發C/C++，同時它還使用智能編輯器來提高代碼質量、自動代碼重構并且深度整合CMake編譯系統，從而提高開發人員的工作效率。

點擊下載CLion最新版本2019.3.4

CLion中項目模型的演變

如您所知，CLion中的所有工作都是在項目上下文中完成的。項目是編碼幫助，批量重構，編碼樣式一致性和其他智能功能的基礎。為了了解項目模型，CLion不僅收集項目文件列表，還收集編譯標志，標頭搜索路徑和特定于項目模型的變量。IDE可以創建聚合這些參數的多個解析配置，您可以在必要時在編輯器中進行切換。

5年前，CLion在僅CMake的項目中啟動，我們在博客中分享了做出該決定的理由。從那時起，CMake在C ++社區中穩定增長，并最終超過Visual Studio，成為C ++開發中最受歡迎的項目模型/構建系統。

但是，在C ++世界中，沒有單一的標準項目模型。有Makefile項目，qmake，msbuild，Bazel，Scons等。Makefile項目位于前三名中，在OSS和嵌入式項目中很受歡迎，并且廣泛用于跨平臺C ++開發，這使它們成為添加到CLion的最佳人選。

在支持Makefile項目的過程中，我們采取了以下步驟：

• 在CLion中打開一個文件夾。在沒有項目模型的情況下，CLion在非常基本的級別上對待所有代碼，并且無法提供任何智能的編碼幫助（例如轉到符號或重構）。
• 編譯數據庫支持。這是一種真正通用的項目格式，可以從任何項目模型（包括任何自定義模型）生成。CLion為此類項目提供了完整的編碼幫助，通常這是在CLion中打開任意項目的最簡單方法。
• 支持自定義構建目標和自定義運行/調試配置。我們添加了此內容是為了豐富編譯數據庫或基于文件夾的項目的經驗，因為CLion可以使用build / clean命令，并且可以運行和調試此類應用程序。

現在，可以使用“自定義構建目標”在CLion中構建，運行和調試任何項目（包括基于Makefile的項目），但它需要準確的手動設置。CMake項目的經驗要好得多– CLion自動檢測可用的目標來構建，以及可執行文件來運行/調試。我們也傾向于為基于Makefile的項目提供這種體驗，但是，這需要大量的啟發和調整。同時，您可以使用現有的Makefile插件來運行make目標（請注意，它不允許運行或調試可執行文件，為此您仍應使用“自定義構建目標”）。

這使我們進入了工作流程，用戶可以在 File Watchers和編譯數據庫的幫助下處理 Makefile項目。主要的痛點是您必須安裝工具才能從Makefile中提取編譯數據庫。但是，工作流是通用的，并且可以在本機不支持的任何項目模型（例如build2或其他模型）上順利運行，如本視頻中的Phil Nash所示。

支持Makefile項目：操作方法

現代C ++工具在IDE中沒有統一的方式來處理Makefile項目。我們已經確定了幾種方法（可在其他IDE和編輯器中使用），概述如下：

選項1：編譯器包裝

有一個名為scan-build的工具，可以通過在構建過程中攔截編譯器調用來幫助您獲取編譯數據庫。第一種方法使用類似的概念– IDE用包裝器（使用CC和CXX環境變量，也通過PATH）替換實際的編譯器，該包裝器將記錄編譯命令，然后調用實際的編譯器。

這種方法的主要好處是它不僅適用于Makefile項目，而且適用于任何構建系統。但是，這需要完整的構建，這可能會花費很長時間，并且可能無法在運行IDE的計算機上執行。

選項2：LD_PRELOAD

這種方法還從當前的工具Bear中獲取了想法，該工具類似于選項1。簡而言之，在類Unix系統上，可以設置LD_PRELOAD環境變量并指定一個動態庫。在執行任何構建過程之前加載。這將允許攔截對編譯器的任何調用。

這種方法對構建過程的干擾較小，這對某些脆弱的配置很重要。但這是特定于Unix的（也可在macOS上使用，但需要一些特殊權限）。

選項3：解析Make的輸出

Make命令在其工作期間會打印出許多有用的輸出，可以將其收集并重用于獲取有關項目的信息。這個想法是第三種方法的基礎。還有一個有用的--just-print選項，它有助于避免在項目重新加載期間實際構建項目，因此與常規的Make調用相比，可以獲得更好的性能。

這種方法看起來不錯，因為它不會影響構建過程，并且使我們可以比完整項目構建更快地收集信息。這也是一個“便攜式”選項，因為理論上IDE可以從記錄在另一臺計算機上的Make輸出開始。因此，盡管這種方法無法擴展到其他構建系統，但在我們看來，它似乎是我們早期研究的首選解決方案。

支持Makefile項目：CLion的原型

正如我們上面提到的，我們決定采用解析Make輸出的方法，而不是通過將用于攔截編譯器調用的工具帶到用戶環境來使用針對Makefile項目的編譯數據庫來自動化解決方法。在這條路線上，我們必須處理許多有趣的子任務：將編譯命令與其他shell命令區分開；了解工作目錄及其混亂的輸出；以及許多其他需要實現特定啟發式的事情。但畢竟，我們已經將其釘牢，并在CLion中獲得了Makefile項目分析器的有效原型：

可能出現的問題

這是真正令人興奮的地方！對大量Makefile項目的內部測試為我們提供了有關如何調整啟發式方法的許多提示。讓我們仔細看一下算法細節，以了解可能出了什么問題。

CLion運行Make，讀取其輸出，然后嘗試解析它，以提取編譯命令和工作目錄。Entering/Leaving directory <dir>輸出中的消息標識我們當前所在的工作目錄。此信息是了解實際正在構建哪個源文件所必需的，因為通常相對于工作目錄指定文件名。在某些項目中，這些消息也被替換為cd <directory> && gcc <file>。準確地提取此信息是算法的關鍵部分。

在這里很容易失敗，因為有很多使Make靜音的技巧。讓我們更深入地了解“制作”選項！GNU Make的默認行為是打印目錄。Makefile可以通過使用.SILENT偽指令來抑制它，但是調用Make with --print-directories會覆蓋它。但是，Makefile可以通過設置來覆蓋它GNUMAKEFLAGS=--no-print-directory，而在GNUMAKEFLAGS=--print-directory調用Make時，可以通過將其作為命令行選項傳遞來覆蓋它。

在目錄內部，輸出消息被視為潛在的編譯命令。CLion嘗試解析它們，尋找已知的編譯器及其標志。在失敗的情況下，該行被視為只是一個文本字符串，因此將被跳過。有趣的是，有一些包裝程序（如libtool）會隱藏編譯標志并干擾Make的輸出，從而使我們當前的方法失敗。Shell和鏈接命令也會產生干擾，但是可以教導算法準確地跳過它們。

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

溫馨提示：疫情期間返崗上班需戴口罩、勤洗手、常通風，做好防護措施！

想要購買Clion正版授權的朋友可以。

更多精彩內容，敬請關注下方的微信公眾號，及時獲取產品最新資訊▼▼▼