xmake後期發展隨想

隨着xmake v2.0.1 版本的發佈，這大半年的辛苦總算告一段落，這個版本我基本上重構整個項目的90%的代碼，幾乎算是重寫了，但結果還算挺滿意的。。

由於上個版本的架構設計的不是很好，不能很好進行擴展，也不支持插件模式，語法設計上也不嚴謹，容易出現各類隱患，這對於後期維護和發展來講，已經出現了不可逾越的瓶頸。。

每一個項目到了必定階段，都是要不斷重構，從新構思總體架構，才能使得項目不斷的向好的方向演進。。

（固然若是是公司項目就另當別論了，坑太多，歷史負擔較重，不是說要重構就能讓你重構的。=。=）

迴歸正題，目前xmake基本上全部模塊都是可擴展的：

• 插件擴展
• 工程模板擴展
• 平臺架構擴展
• action擴展
• option選項擴展
• 自定義task任務機制
• 宏腳本擴展

模塊化和可擴展性，使得xmake總體是高度解耦的，整個core的內核算法實現很是輕量，其餘模塊若是咱們想要擴展它，只須要把本身實現的腳本放到對應目錄，就能夠實現自注冊，自加載。。

而且每一個插件模塊內部都有嚴格的做用域控制、沙盒化處理，很是安全，不會干擾到其餘插件。。

下一個大版本，我打算開始研究下，怎麼去實現完善的依賴包管理，目前的一些想法和構思：

• 自動檢測依賴包，若是存在直接連接編譯，若是不存在，從遠程倉庫中自動下載對應版本，進行本地編譯安裝，而後自動集成和連接

• 支持多架構、多平臺以及交叉平臺的包管理

• 參考homebrew的包管理思想，將倉庫放在項目中，經過git維護

• 爲了實現交叉平臺的包管理，倉庫的包描述，除了提供包原代碼的url外，還提供移植描述腳本

可能我說的有點模糊，先說說現有的一些包管理工具，例如：homebrew、apt-get、pacman等等。。

大同小異，都是下載、自動編譯、安裝集成到系統中，不過都只能支持pc原有的主機平臺，並不支持交叉平臺

例如：在windows上我要自動加載安裝一個ios armv7s的包，集成到個人項目中。。這就不行了。

而xmake的下個版本，打算作的就是這個，簡單的說：

我要作一個移植倉庫，實現一人移植，萬人使用

之後，若是用xmake編譯項目，這個項目中說須要連接 android 版本 armv7-a 的 libpng.a，那麼xmake 就會先檢測本地倉庫是否存在，不存在的話，就會從移植倉庫中，check處移植腳本，自動進行本地移植編譯，而後連接到這個項目中去。。。

明白了嗎，是否是頗有趣。。？

如今的開源項目愈來愈多，平臺也愈來愈多，可是不少c/c++項目的移植工做至關麻煩，不一樣項目編譯方式區別很大，平臺支持力度也各不同。。

而咱們日常移植後，基本上只能本身使用，無法分享給別人

而下個版本，xmake要作的就是讓其餘人不用從新再移植一邊，只要有人移植過，把移植過程記錄成移植腳本，push到xmake的移植倉庫中，讓全部人共享移植成果。。這是多美妙的一件事哈。。：）

我表達能力有限，貌似有點囉嗦了，最後我對xmake的指望就是：

它不只僅是個跨平臺構建工具，也將會成爲移植神器，一人移植，萬人共享就是xmake的目標！

---

• XMake項目詳情
• XMake項目源碼
• XMake項目文檔