在bp檔案中新增編譯控制

適用平台：q平台、r平台

遇到的問題：在產品的boardconfig.mk中定義的編譯控制，只能在android.mk檔案中使用，無法在android.bp檔案使用。

上圖中的 debuggable 關鍵字就是編譯控制，意思是編譯debug版本時設定兩個巨集定義為1（預設為0）。

搜尋原始碼，在build/make/core/soong_config.mk檔案中找到了 debuggable 的定義，實現了target_build_variant （mk中定義）和 debuggable（bp中使用）的關聯，截圖如下：

在build/soong/android/variable.go檔案中找到了 debuggable 結構的定義，結構體中指明了可以控制的範圍，截圖如下：

下面我們來定義自己的控制feature，作用是控制user版本上remount功能的開啟。預設情況下，user版本時不支援remount功能的，為了除錯的方便，新增了編譯控制。在需求存在的情況下，可以編譯出支援remount功能的user版本，提高開發效率。下面給出詳細的新增步驟。

1、在build/make/core/soong_config.mk檔案中定義 remount_on_user 編譯控制，和boardconfig.mk中的 product_allow_remount_on_user 關聯。

2、在build/soong/android/variable.go檔案中新增如下兩部分。

定義 remount_on_user 為 productvariables struct 中的乙個變數

定義 remount_on_user 結構中包含的控制變數（cflags， cppflags， rc檔案，模組依賴）

3、在 system/core/fs_mgr/android.bp 中進行了應用，相當於在user版本上增加了debug版本的編譯巨集控制，截圖如下。

4、在 boardconfig.mk 中定義編譯feature，需要的時候開啟如下feature就可以，可有效減小專案的維護成本。

5、到此，工作就結束了。但是我們在編譯時怎麼知道這個feature是否配置了呢，怎麼在不看**的情況下知道呢。

在build/soong/ui/build/dumpvars.go中新增feature的列印。

這樣在lunch編譯目標後，如果在 boardconfig.mk 中定義了feature，就可以看到如下列印。