較大型cpp專案的**組織、編譯都是深耦合的。
一般提供乙個總體的makefile，進入各個模組，又有自己的makefile，這些makefile又都依賴於一些被include的檔案的的定義，為什麼要這樣原因不必多言。
但要想改變編譯環境時，卻很難順利的移植。我們可能踩過的坑有：
1）找不到類庫，這個還比較好處理，絕對是你指定的目錄問題，甚至是當前目錄——乙個小圓點不要疏忽了
2）依賴庫不匹配，比如glibc、i686、x86_64等，只管去匹配好了
3）還是找不到定義:注意調整依賴的順序，一般越是通用、沒有耦合的庫要盡可能放在後面，讓前面找不到定義的庫有機會去查詢，還有就是雙向關聯的類——做好宣告。
如何定位一些原因，必須學會如下命令：
搞清楚各個庫的版本，尤其是libc的
可以用（ldd --version 檢視glibc的版本，如ldd (gnu libc) 2.12； 命令/lib64/libc.so.6也可以）
這裡再補充些網上找來的資源：
編譯源**時，鏈結的時候查詢順序是:
(1) -l 指定的路徑, 從左到右依次查詢
(2) 由環境變數 library_path 指定的路徑,使用":"分割從左到右依次查詢
(3) /etc/ld.so.conf 指定的路徑順序
(4) /lib 和 /usr/lib (64位下是/lib64和/usr/lib64)
動態庫呼叫的查詢順序:
(1) ld的-rpath引數指定的路徑, 這是寫死在**中的
(2) ld指令碼指定的路徑
(3) ld_library_path 指定的路徑
(4) /etc/ld.so.conf 指定的路徑
(5)/lib和/usr/lib(64位下是/lib64和/usr/lib64)
一般情況鏈結的時候我們採用-l的方式指定查詢路徑, 呼叫動態鏈結庫的時候採用ld_library_path的方式指定鏈結路徑。
另外注意乙個問題,就是只要查詢到第乙個就會返回,後面的不會再查詢.
makefile中對作業系統的判斷:
arch = $(shell getconf long_bit)
uname -m
ifeq ($(os_type), x86_64) lib_epoll =
else lib_epoll = -lepoll
endif
待續
正確地組織python專案的結構
寫了不少python專案後,越來越認識到python專案結構重要性.不管專案是否要開源,是否要提交pypi,專案結構的一致性帶來的好處還有很多 多人合作開發大家都有個基本的guideline,別人日後維護也方便,也容易形成專案開發的best practice.所以花了寫時間,仔細研究了github上...
專案管理一般知識 專案的組織方式
專案的組織方式可以分為 職能型 職能型適用於規模較小 偏重於技術的專案 專案型 專案型適用於規模較大 技術複雜時的專案 矩陣型 矩陣型適用於規模巨大 技術複雜的專案。矩陣型又可細分為 弱矩陣型 平衡矩陣型 又稱中矩陣 強矩陣型。所謂強和弱都是相對專案中專案經理的權力而言的，比如弱矩陣中專案經理的權力...
資訊系統監理 監理專案的組織和規劃
在監理工作實施前,包括簽訂監理委託合同和組建監理專案部的前後,監理單位就要以總監理工程師和專業監理工程師為主,開始逐步進行監理工作的計畫.在這期間,產生的計畫性檔案主要包括監理大綱 監理規劃和監理實施細則.下面讓我們一起來學習一下這三種指導檔案的作用和聯絡吧 監理大綱是在建設單位選擇合適的監理單位時...