Android.mk：如何检查模块是否已存在

Question

我正在尝试为现有构建环境自动生成 Android.mk 文件。这个环境有许多相互链接的库，也可能链接到第 3 方库（如 boost）。

假设我有 libA 使用 boost。 我的目标是通过从 libB 文件夹运行 ndk-build 来构建 libA 和 libB。

所以我为libA 生成了这个Android.mk：

LOCAL_PATH := $(call my-dir)

# Import boost
include $(CLEAR_VARS)
LOCAL_MODULE    := boost_atomic
LOCAL_SRC_FILES := ../dev/libcpp/boost/1.60.1/lib/libboost_atomic.a
include $(PREBUILT_STATIC_LIBRARY)

# libA:
include $(CLEAR_VARS)
LOCAL_MODULE    := libA
LOCAL_SRC_FILES := libA.cpp
LOCAL_C_INCLUDES := ../dev/libcpp/boost/1.60.1

# boost import:
LOCAL_CPPFLAGS += -DHAVE_CONFIG_H -fexceptions -frtti
LOCAL_STATIC_LIBRARIES += boost_atomic

# build libA:
include $(BUILD_SHARED_LIBRARY)

现在我有libB 使用boost 和libA。 libB 的Android.mk 与libA 非常相似，只是我添加了libA 文件的导入，如下所示：

# Import libA
include $(CLEAR_VARS)
LOCAL_MODULE := libA
include ../../libA/jni/Android.mk

当我尝试制作libB 时，我被举报了：

Android NDK: Trying to define local module 'boost_atomic' in ../../libA/jni/Android.mk.
Android NDK: But this module was already defined by ../../libA/jni/Android.mk.
B:/Android/android-ndk-r11b/build//../build/core/build-module.mk:34: *** Android
 NDK: Aborting.    .  Stop.

有没有办法让我检查boost_atomic 是否已经定义（如if (exists boost_atomic)）以确保它只被定义一次？或者我应该为所有名称添加后缀（以boost_system_for_libA 和boost_system_for_libB 结尾）以防止冲突？还是有其他选择？

Answer 1

您有一个 NDK 函数$(modules_get_list)。依靠它，您的 libA/jni/Android.mk 文件可能如下所示：

LOCAL_PATH := $(call my-dir)

include ../../boost/Android.mk

# libA:
include $(CLEAR_VARS)
LOCAL_MODULE    := libA
LOCAL_SRC_FILES := libA.cpp

# boost import:
LOCAL_STATIC_LIBRARIES += boost_atomic

# build libA:
$(if $(call set_is_member,$(modules-get-list),$(LOCAL_MODULE)),\
    ,$(eval include $(BUILD_SHARED_LIBRARY)))

和boost/Android.mk文件：

LOCAL_PATH := $(call my-dir)

# Import boost
include $(CLEAR_VARS)
LOCAL_MODULE    := boost_atomic
LOCAL_SRC_FILES := ../dev/libcpp/boost/1.60.1/lib/libboost_atomic.a
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/../dev/libcpp/boost/1.60.1
LOCAL_EXPORT_CPPFLAGS += -DHAVE_CONFIG_H -fexceptions -frtti
$(if $(call set_is_member,$(modules-get-list),$(LOCAL_MODULE)),\
    ,$(eval include $(PREBUILT_STATIC_LIBRARY))

最后，libB/jni/Android.mk：

LOCAL_PATH := $(call my-dir)

include ../../boost/Android.mk
include ../../libA/jni/Android.mk

# libB:
include $(CLEAR_VARS)
LOCAL_MODULE    := libB
LOCAL_SRC_FILES := libB.cpp

# boost import:
LOCAL_STATIC_LIBRARIES += boost_atomic

# build libA:
$(if $(call set_is_member,$(modules-get-list),$(LOCAL_MODULE)),\
    ,$(eval include $(BUILD_SHARED_LIBRARY)))

我不希望对第 3 方预构建库（如 boost）有重复的定义，而是为每个库使用单独的 Android.mk 定义，并在必要时使用include。这样，如果外部库更新，我就有一个地方可以更改。

更新：如果你不喜欢$(if …) 语法，你可以使用

ifeq ($(filter $(modules-get-list),$(LOCAL_MODULE)),)
    include $(BUILD_…_LIBRARY)
endif

改为。

Answer 2

正如 Alex Cohn 所提到的，人们可以通过替换来解决这个问题：

include $(CLEAR_VARS)
LOCAL_MODULE    := boost_atomic
LOCAL_SRC_FILES := ../dev/libcpp/boost/1.60.1/lib/libboost_atomic.a
include $(PREBUILT_STATIC_LIBRARY)

...

# boost import:
LOCAL_CPPFLAGS += -DHAVE_CONFIG_H -fexceptions -frtti
LOCAL_STATIC_LIBRARIES += boost_atomic

简单地说：

LOCAL_LDLIBS += ../dev/libcpp/boost/1.60.1/lib/libboost_atomic.a

这可行，但是：

• 引入编译警告：

  警告：/Users/jwalton/Android-CryptoPP/jni/Android.mk:prng： 链接器标志中的非系统库：-lcryptopp -lstlport_shared
  这很可能导致不正确的构建。尝试使用 LOCAL_STATIC_LIBRARIES
  或 LOCAL_SHARED_LIBRARIES 来列出 当前模块

• 不适用于共享的第三方库

所以我终于解决了这个问题，我添加了一个特定于libA、libB 的新 mk 文件：

libA 的Android.mk 现在是：

LOCAL_PATH := $(call my-dir)

# Import boost
include $(CLEAR_VARS)
LOCAL_MODULE    := boost_atomic
LOCAL_SRC_FILES := ../dev/libcpp/boost/1.60.1/lib/libboost_atomic.a
include $(PREBUILT_STATIC_LIBRARY)

include libA.mk

libA 的libA.mk 现在是：

LOCAL_PATH := $(call my-dir)

# libA:
include $(CLEAR_VARS)
LOCAL_MODULE    := libA
LOCAL_SRC_FILES := libA.cpp
LOCAL_C_INCLUDES := ../dev/libcpp/boost/1.60.1

# boost link:
LOCAL_CPPFLAGS += -DHAVE_CONFIG_H -fexceptions -frtti
LOCAL_STATIC_LIBRARIES += boost_atomic

# build libA:
include $(BUILD_SHARED_LIBRARY)

libB 的libB.mk 现在有：

# Import libA
include $(CLEAR_VARS)
LOCAL_MODULE := libA
include ../../libA/jni/libA.mk

所以它导入libA而不导入boost（也在libB的Android.mk中定义）。

然后，没有警告，它编译顺利。

Answer 3

我正在尝试为现有的自动生成 Android.mk 文件 构建环境。这个环境有很多库链接到每个 其他也可能链接到第 3 方库（如 boost）。

为什么不使用standalone NDK toolchains 而不是痛苦地处理Android.mk 文件？听起来独立工具链非常适合您的情况。