Androidシステムのコンパイル時に遭遇したいくつかの.mkの疑惑.
4306 ワード
Android 4.2のソースコードBuild/prduct_config.mkではいくつかの疑問に直面しています.
Makefileはproduct_を読み込んでいますconfig.mkファイルの場合、TARGET_DEVICEの第一感覚は私の合成変数を理解されるべきで、もちろんこれはMakefileの原理です.しかし、ここで発見されたのはそうではありません.なぜですか.nodeが導入されたのでfns.mkファイル.このファイルの役割は、例えばマクロ形式が定義されているように、終了したcontentがその論理に従って処理されるべきであることを規定しています.その後の変数処理は実際には別の処理方法になります.
例えば、ここで実際には:
INTERNAL_PRODUCT = device/softwinner/fiber-3g/fiber_3g.mk
TARGET_DEVICE = fiber-3g
正直に言って自分もよく理解していませんnode_fns.mkの役割は、多くのマクロを定義したヘッダファイルとして理解しましょう.
下老羅のAndroidの旅を見て、収穫してよかったです.上記の内容は実質的に$(PRODUCTS.$(INTERNAL_PRODUCT)である.PRODUCT_DEVICE)は新しい変数です.AndroidProducts.mkの内容を分析し、異なる_を加えます.product_var_listは、新しい変数を生成することができ、異なる独自のカスタマイズされた製品に基づいて生成されます.以下の変数は前述のTARGET_になります.DEVICE、本質はAndroid Products.mkでは定義されています.
Androidシステムの場合.mkファイルはsource/build/envsetup.sh後に呼び出す.例:
このスクリプト関数はlunch選択時にchenk productsの操作を行いget_をさらに実行するbuild_var TARGET_DEVICEの関数処理.本質的には1回のMakeの操作を実行した.システムコンパイルのMake-j 8などと完全に似ているように見えます.ただ彼が実行したのはconfigだけだ.mk構成に関する内容だけです.さらにenvsetupを順次実行する.mk,product_へconfig.mk,最終取得TARGET_DEVICE変数の内容.
6.$DEVICE変数の生成プロセスは、ファイルfiber-3 gが存在するパスです.
まずsource envsetup.shすべてのデバイスとvendorの下のvendorsetup.shを追加し、comboの統合を完了します.
lunch関数対応するプラットフォームを選択すると、コンパイルに必要なすべての環境変数が次の関数で完了するように設定されます.
#環境変数set_を設定stuff_for_Environment#最終構成情報を印刷printconfig
set_stuff_for_Environmentのsetpath関数では、後続のスクリプト関数の呼び出しを実行するためにexportの多くの環境パスが使用されます.
EXport DEVICEを含むインポートがあります.
tdevice=$(get_build_var TARGET_DEVICE)
export DEVICE=$T/device/*/$tdevice
以下のようにAndroidコンパイル項目をカスタマイズし、Product製品プロファイル、Boardボードレベルプロファイルを作成します.
7 lunchプロセスでTARGET_が決定されましたPRODUCT = fiber_3 gの内容;
8
TARGET_DEVICE=fiber-3 g、
build/core/product_config.mk
に基づいて
PRODUCT_DEVICEで確定
.
すべてのデバイスディレクトリの下にあるAndroid Productsを巡る.mkに導入する.mkファイル、例えばfiber_3g.mk.TARGET_を通過PRODUCTは、対応するAndroid Productsを検索するために一致します.mk.そしてPRODUCT_DEVICEはfiber_にあります3g.mkではfiber−3 gと決定された.node_を通過fns.mkのマクロ作用、さらに決定
TARGET_DEVICEの内容はfiber-3 gです.
9.Boardconfig.mkの役割.build/core/config.mkが決める.デバイス/*/$(TARGET_DEVICE)/boardconfigを巡回することにより.mkで完成
# Convert a short name like "sooner" into the path to the product
# file defining that product.
#
INTERNAL_PRODUCT := $(call resolve-short-product-name, $(TARGET_PRODUCT))
ifneq ($(current_product_makefile),$(INTERNAL_PRODUCT))
$(error PRODUCT_NAME inconsistent in $(current_product_makefile) and $(INTERNAL_PRODUCT))
endif
current_product_makefile :=
all_product_makefiles :=
all_product_configs :=
# Find the device that this product maps to.
TARGET_DEVICE := $(PRODUCTS.$(INTERNAL_PRODUCT).PRODUCT_DEVICE)
Makefileはproduct_を読み込んでいますconfig.mkファイルの場合、TARGET_DEVICEの第一感覚は私の合成変数を理解されるべきで、もちろんこれはMakefileの原理です.しかし、ここで発見されたのはそうではありません.なぜですか.nodeが導入されたのでfns.mkファイル.このファイルの役割は、例えばマクロ形式が定義されているように、終了したcontentがその論理に従って処理されるべきであることを規定しています.その後の変数処理は実際には別の処理方法になります.
例えば、ここで実際には:
INTERNAL_PRODUCT = device/softwinner/fiber-3g/fiber_3g.mk
TARGET_DEVICE = fiber-3g
正直に言って自分もよく理解していませんnode_fns.mkの役割は、多くのマクロを定義したヘッダファイルとして理解しましょう.
下老羅のAndroidの旅を見て、収穫してよかったです.上記の内容は実質的に$(PRODUCTS.$(INTERNAL_PRODUCT)である.PRODUCT_DEVICE)は新しい変数です.AndroidProducts.mkの内容を分析し、異なる_を加えます.product_var_listは、新しい変数を生成することができ、異なる独自のカスタマイズされた製品に基づいて生成されます.以下の変数は前述のTARGET_になります.DEVICE、本質はAndroid Products.mkでは定義されています.
# Overrides
PRODUCT_BRAND := Softwinner
PRODUCT_NAME := fiber_3g
PRODUCT_DEVICE := fiber-3g
PRODUCT_MODEL := Softwinn
PRODUCTS.build/target/product/full.mk.PRODUCT_NAME := fiber_3g
PRODUCTS.build/target/product/full.mk.PRODUCT_DEVICE := fiber-3g
_product_var_list := \
PRODUCT_NAME \
PRODUCT_MODEL \
PRODUCT_LOCALES \
PRODUCT_AAPT_CONFIG \
PRODUCT_AAPT_PREF_CONFIG \
PRODUCT_PACKAGES \
PRODUCT_PACKAGES_DEBUG \
PRODUCT_PACKAGES_ENG \
PRODUCT_PACKAGES_TESTS \
PRODUCT_DEVICE \
PRODUCT_MANUFACTURER \
PRODUCT_BRAND \
PRODUCT_PROPERTY_OVERRIDES \
PRODUCT_DEFAULT_PROPERTY_OVERRIDES \
PRODUCT_CHARACTERISTICS \
PRODUCT_COPY_FILES \
PRODUCT_OTA_PUBLIC_KEYS \
PRODUCT_EXTRA_RECOVERY_KEYS \
PRODUCT_PACKAGE_OVERLAYS \
DEVICE_PACKAGE_OVERLAYS \
PRODUCT_TAGS \
PRODUCT_SDK_ADDON_NAME \
PRODUCT_SDK_ADDON_COPY_FILES \
PRODUCT_SDK_ADDON_COPY_MODULES \
PRODUCT_SDK_ADDON_DOC_MODULES \
PRODUCT_DEFAULT_WIFI_CHANNELS \
PRODUCT_DEFAULT_DEV_CERTIFICATE \
PRODUCT_RESTRICT_VENDOR_FILES \
PRODUCT_VENDOR_KERNEL_HEADERS \
PRODUCT_FACTORY_RAMDISK_MODULES \
PRODUCT_FACTORY_BUNDLE_MODULES
Androidシステムの場合.mkファイルはsource/build/envsetup.sh後に呼び出す.例:
function get_build_var()
{
T=$(gettop)
if [ ! "$T" ]; then
echo "Couldn't locate the top of the tree. Try setting TOP." >&2
return
fi
CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \
make --no-print-directory -C "$T" -f build/core/config.mk dumpvar-$1
}
このスクリプト関数はlunch選択時にchenk productsの操作を行いget_をさらに実行するbuild_var TARGET_DEVICEの関数処理.本質的には1回のMakeの操作を実行した.システムコンパイルのMake-j 8などと完全に似ているように見えます.ただ彼が実行したのはconfigだけだ.mk構成に関する内容だけです.さらにenvsetupを順次実行する.mk,product_へconfig.mk,最終取得TARGET_DEVICE変数の内容.
6.$DEVICE変数の生成プロセスは、ファイルfiber-3 gが存在するパスです.
まずsource envsetup.shすべてのデバイスとvendorの下のvendorsetup.shを追加し、comboの統合を完了します.
lunch関数対応するプラットフォームを選択すると、コンパイルに必要なすべての環境変数が次の関数で完了するように設定されます.
#環境変数set_を設定stuff_for_Environment#最終構成情報を印刷printconfig
set_stuff_for_Environmentのsetpath関数では、後続のスクリプト関数の呼び出しを実行するためにexportの多くの環境パスが使用されます.
EXport DEVICEを含むインポートがあります.
tdevice=$(get_build_var TARGET_DEVICE)
export DEVICE=$T/device/*/$tdevice
以下のようにAndroidコンパイル項目をカスタマイズし、Product製品プロファイル、Boardボードレベルプロファイルを作成します.
7 lunchプロセスでTARGET_が決定されましたPRODUCT = fiber_3 gの内容;
8
TARGET_DEVICE=fiber-3 g、
build/core/product_config.mk
に基づいて
PRODUCT_DEVICEで確定
.
すべてのデバイスディレクトリの下にあるAndroid Productsを巡る.mkに導入する.mkファイル、例えばfiber_3g.mk.TARGET_を通過PRODUCTは、対応するAndroid Productsを検索するために一致します.mk.そしてPRODUCT_DEVICEはfiber_にあります3g.mkではfiber−3 gと決定された.node_を通過fns.mkのマクロ作用、さらに決定
TARGET_DEVICEの内容はfiber-3 gです.
9.Boardconfig.mkの役割.build/core/config.mkが決める.デバイス/*/$(TARGET_DEVICE)/boardconfigを巡回することにより.mkで完成