分布式編譯

1. "XGConsole"錯誤是缺少編譯軟體么

../Res_MMI/Res_MainMenu.c: In function `PopulateMainMenuRes':../Res_MMI/Res_MainMenu.c:2093: error: parse error before "MENU_ID_CAMERA_APP"make[1]: *** [Res_MainMenu.o] Error 1大家都說缺少分布式編譯軟體

2. 編譯器算是分布式系統結構嗎

驢唇不對馬嘴。前者是一種翻譯程序，後者是一種計算機系統的體系結構。

3. android系統編譯能用分布式編譯嗎

項目越來越大，每次需要重新編譯整個項目都是一件很浪費時間的事情。Research了一下，找到以下可以幫助提高速度的方法，總結一下。
1. 使用tmpfs來代替部分IO讀寫
2.ccache，可以將ccache的緩存文件設置在tmpfs上，但是這樣的話，每次開機後，ccache的緩存文件會丟失
3.distcc,多機器編譯
4.將屏幕輸出列印到內存文件或者/dev/null中，避免終端設備（慢速設備）拖慢速度。

tmpfs
有人說在Windows下用了RAMDisk把一個項目編譯時間從4.5小時減少到了5分鍾，也許這個數字是有點誇張了，不過粗想想，把文件放到內存上做編譯應該是比在磁碟上快多了吧，尤其如果編譯器需要生成很多臨時文件的話。
這個做法的實現成本最低，在linux中，直接mount一個tmpfs就可以了。而且對所編譯的工程沒有任何要求，也不用改動編譯環境。
mount -t tmpfs tmpfs ~/build -o size=1G
用2.6.32.2的Linux Kernel來測試一下編譯速度：
用物理磁碟：40分16秒
用tmpfs：39分56秒
呃……沒什麼變化。看來編譯慢很大程度上瓶頸並不在IO上面。但對於一個實際項目來說，編譯過程中可能還會有打包等IO密集的操作，所以只要可能，用tmpfs是有益無害的。當然對於大項目來說，你需要有足夠的內存才能負擔得起這個tmpfs的開銷。
make -j
既然IO不是瓶頸，那CPU就應該是一個影響編譯速度的重要因素了。
用make -j帶一個參數，可以把項目在進行並行編譯，比如在一台雙核的機器上，完全可以用make -j4，讓make最多允許4個編譯命令同時執行，這樣可以更有效的利用CPU資源。
還是用Kernel來測試：
用make： 40分16秒
用make -j4：23分16秒
用make -j8：22分59秒
由此看來，在多核CPU上，適當的進行並行編譯還是可以明顯提高編譯速度的。但並行的任務不宜太多，一般是以CPU的核心數目的兩倍為宜。
不過這個方案不是完全沒有cost的，如果項目的Makefile不規范，沒有正確的設置好依賴關系，並行編譯的結果就是編譯不能正常進行。如果依賴關系設置過於保守，則可能本身編譯的可並行度就下降了，也不能取得最佳的效果。
ccache
ccache工作原理：
ccache也是一個編譯器驅動器。第一趟編譯時ccache緩存了GCC的「-E」輸出、編譯選項以及.o文件到$HOME/.ccache。第二次編譯時盡量利用緩存，必要時更新緩存。所以即使"make clean; make"也能從中獲得好處。ccache是經過仔細編寫的，確保了與直接使用GCC獲得完全相同的輸出。

ccache用於把編譯的中間結果進行緩存，以便在再次編譯的時候可以節省時間。這對於玩Kernel來說實在是再好不過了，因為經常需要修改一些Kernel的代碼，然後再重新編譯，而這兩次編譯大部分東西可能都沒有發生變化。對於平時開發項目來說，也是一樣。為什麼不是直接用make所支持的增量編譯呢？還是因為現實中，因為Makefile的不規范，很可能這種「聰明」的方案根本不能正常工作，只有每次make clean再make才行。
安裝完ccache後，可以在/usr/local/bin下建立gcc，g++，c++，cc的symbolic link，鏈到/usr/bin/ccache上。總之確認系統在調用gcc等命令時會調用到ccache就可以了（通常情況下/usr/local /bin會在PATH中排在/usr/bin前面）。
安裝的另外一種方法：
vi ~/.bash_profile
把/usr/lib/ccache/bin路徑加到PATH下
PATH=/usr/lib/ccache/bin:$PATH:$HOME/bin
這樣每次啟動g++的時候都會啟動/usr/lib/ccache/bin/g++，而不會啟動/usr/bin/g++
效果跟使用命令行ccache g++效果一樣
這樣每次用戶登錄時，使用g++編譯器時會自動啟動ccache
繼續測試：
用ccache的第一次編譯(make -j4)：23分38秒
用ccache的第二次編譯(make -j4)：8分48秒
用ccache的第三次編譯(修改若干配置，make -j4)：23分48秒

看來修改配置（我改了CPU類型...）對ccache的影響是很大的，因為基本頭文件發生變化後，就導致所有緩存數據都無效了，必須重頭來做。但如果只是修改一些.c文件的代碼，ccache的效果還是相當明顯的。而且使用ccache對項目沒有特別的依賴，布署成本很低，這在日常工作中很實用。
可以用ccache -s來查看cache的使用和命中情況：
cache directory /home/lifanxi/.ccachecache hit 7165cache miss 14283called for link 71not a C/C++ file 120no input file 3045files in cache 28566cache size 81.7 Mbytesmax cache size 976.6 Mbytes
可以看到，顯然只有第二編次譯時cache命中了，cache miss是第一次和第三次編譯帶來的。兩次cache佔用了81.7M的磁碟，還是完全可以接受的。
distcc
一台機器的能力有限，可以聯合多台電腦一起來編譯。這在公司的日常開發中也是可行的，因為可能每個開發人員都有自己的開發編譯環境，它們的編譯器版本一般是一致的，公司的網路也通常具有較好的性能。這時就是distcc大顯身手的時候了。
使用distcc，並不像想像中那樣要求每台電腦都具有完全一致的環境，它只要求源代碼可以用make -j並行編譯，並且參與分布式編譯的電腦系統中具有相同的編譯器。因為它的原理只是把預處理好的源文件分發到多台計算機上，預處理、編譯後的目標文件的鏈接和其它除編譯以外的工作仍然是在發起編譯的主控電腦上完成，所以只要求發起編譯的那台機器具備一套完整的編譯環境就可以了。
distcc安裝後，可以啟動一下它的服務：
/usr/bin/distccd --daemon --allow 10.64.0.0/16
默認的3632埠允許來自同一個網路的distcc連接。
然後設置一下DISTCC_HOSTS環境變數，設置可以參與編譯的機器列表。通常localhost也參與編譯，但如果可以參與編譯的機器很多，則可以把localhost從這個列表中去掉，這樣本機就完全只是進行預處理、分發和鏈接了，編譯都在別的機器上完成。因為機器很多時，localhost的處理負擔很重，所以它就不再「兼職」編譯了。
export DISTCC_HOSTS="localhost 10.64.25.1 10.64.25.2 10.64.25.3"
然後與ccache類似把g++，gcc等常用的命令鏈接到/usr/bin/distcc上就可以了。
在make的時候，也必須用-j參數，一般是參數可以用所有參用編譯的計算機CPU內核總數的兩倍做為並行的任務數。
同樣測試一下：
一台雙核計算機，make -j4：23分16秒
兩台雙核計算機，make -j4：16分40秒
兩台雙核計算機，make -j8：15分49秒
跟最開始用一台雙核時的23分鍾相比，還是快了不少的。如果有更多的計算機加入，也可以得到更好的效果。
在編譯過程中可以用distccmon-text來查看編譯任務的分配情況。distcc也可以與ccache同時使用，通過設置一個環境變數就可以做到，非常方便。
總結一下：
tmpfs： 解決IO瓶頸，充分利用本機內存資源
make -j： 充分利用本機計算資源
distcc： 利用多台計算機資源
ccache： 減少重復編譯相同代碼的時間
這些工具的好處都在於布署的成本相對較低，綜合利用這些工具，就可以輕輕鬆鬆的節省相當可觀的時間。上面介紹的都是這些工具最基本的用法，更多的用法可以參考它們各自的man page。
5.還有提速方法是把屏幕輸出重定向到內存文件或/dev/null,因對終端設備(慢速設備)的阻塞寫操作也會拖慢速度。推薦內存文件，這樣發生錯誤時，能夠查看。

4. MTK分布式編譯系統的組成

本系統由注冊伺服器、編譯伺服器和客戶端組成。網內啟動一個注冊伺服器，多個編譯伺服器。在MTK6223平台上，單機new一次需要50分鍾的項目。使用10個編譯伺服器同時編譯，new一次需要13分鍾。模塊編譯之前是在客戶端工作的，需要9分鍾，其中為了實現分布式編譯，壓縮源代碼佔用了2分鍾，文件下載到編譯伺服器需要2分鍾。從第一個模塊編譯到最後link之前，10台機器僅用4分鍾就完成了1200個c文件的編譯工作。最後的link是在本機進行的，幾十秒就完了。我曾經試過18台機器同時編譯，1200個c文件不到2分鍾就編譯完成了，當然下載時間需要3分鍾。對於開發人員來講，new一次不再是夢魘。
當然，不能無限制地增加編譯伺服器，要考慮文件傳輸所消耗的時間。MTK平台文件很多，需要由客戶端向伺服器分發。一般地，一個客戶端與十個伺服器聯合編譯可以達到理想效果。

5. distcc 分布式編譯 怎麼部署

編譯配置編譯前 （不建議寫到環境變數中） 在"build/core/combo"文件夾下TARGET_linux-arm.mk文件： select.mk文件： 啟動編譯 監視編譯distcc自帶distccmon-text，可以啟動文本化監視 也可使用distccmon-gnome啟動圖形化監視程序

6. mac上有沒有分布式編譯c++代碼工具

當然可以。
MAC系統是free-bsd（unix的一種開源系統分支）為基礎，逐步演化而來的。
實際MAC也是屬於UNIX大家族。
只要安裝了c的編譯器，就可以用C編程。
當然在mac上，蘋果以object-c提供了一套豐富的api，包括對其圖形界面的互動。

7. incredibuild 怎麼使用，怎麼把自己的機器和區域網的機器都連接上

1.確認連接是否有問題；
2.make.exe是否支持分布式編譯？我個人知道GNU MAKE 3.8.1支持分布式編譯；
3.是否有對應的啟動分布式編譯的.xml文件？如果沒有就找一個或者自己寫一個；
4.編譯的時候不只單單輸入make命令，要配合.xml命令；

8. c++分離式編譯的好處是什麼

1、如果有錯誤能快速找到。
2、實現模塊多用。

分離編譯模式是指：一個程序（項目）由若干個源文件共同實現，而每個源文件單獨編譯生成目標文件，最後將所有目標文件連接起來形成單一的可執行文件的過程。
分離編譯模式是C/C++組織源代碼和生成可執行文件的方式。在實際開發大型項目的時候，不可能把所有的源程序都放在一個頭文件中，而是分別由不同的程序員開發不同的模塊，再將這些模塊匯總成為最終的可執行程序。
這里就涉及到不同的模塊（源文件）定義的函數和變數之間的相互調用問題。C/C++語言所採用的方法是：只要給出函數原型（或外部變數聲明），就可以在本源文件中使用該函數（或變數）。每個源文件都是獨立的編譯單元，在當前源文件中使用但未在此定義的變數或者函數，就假設在其他的源文件中定義好了。每個源文件生成獨立的目標文件（obj文件），然後通過連接（Linking）將目標文件組成最終的可執行文件。
程序編譯的簡要過程包括預處理(Preprocessing)、編譯(Compilation)、匯編(Assembly)和連接(Linking)。

9. 有沒有用於java語言的分布式編譯工具

maven和ant都可以實現，但是需要配置。

10. 什麼是分布式處理要求通俗，易懂。感謝！

分布式處理系統與並行處理系統都是計算機體系結構中的兩類。並行處理系統是利用多個功能部件或多個處理機同時工作來提高系統性能或可靠性的計算機系統，這種系統至少包含指令級或指令級以上的並行。並行處理系統的研究與發展涉及計算理論，演算法，體系結構，軟硬體多個方面，但它與分布式處理系統有密切的關系，隨著通信技術的發展，兩者的界限越來越模糊。廣義上說分布式處理也可以認為是一種並行處理形式。而分布式處理系統將不同地點的或具有不同功能的或擁有不同數據的多台計算機用通信網路連接起來，在控制系統的統一管理控制下，協調地完成信息處理任務的計算機系統。一般認為，集中在同一個機櫃內或同一個地點的緊密耦合多處理機系統或大規模並行處理系統是並行處理系統，而用區域網或廣域網連接的計算機系統是分布式處理系統。鬆散耦合並行計算機中的並行操作系統有時也稱為分布式處理系統。
分布式處理系統包含硬體，控制系統，介面系統，數據，應用程序和人等六個要素。而控制系統中包含了分布式操作系統，分布式資料庫以及通信協議等。
分布式計算環境是在具有多地址空間的多計算機系統上進行計算和信息處理的軟體環境。而分布式軟體系統是支持分布式處理的軟體系統，它包括分布式操作系統，分布式程序設計語言及其編譯系統，分布式文件系統和分布式資料庫系統等。而CORBA，COM＋等是設計分布式軟體系統的一些技術。

通俗地講（一通俗就不是很科學了，你可以參照上邊的說法），分布式處理就是多台相連的計算機各自承擔同一工作任務的不同部分，在人的控制下，同時運行，共同完成同一件工作任務．