Я бы не рекомендовал делать это таким образом. Распространение всего NDK звучит как излишнее распределение ваших библиотек. Я думаю, что вы (и, что более важно, ваши пользователи) будут лучше обслуживаться более традиционным методом распространения.
У нас есть инструмент под названием cdep , который может помочь с этим, но генерируемая им интеграция системы сборки не является идиоматичной для CMake, так что это не может быть вашим предпочтительным вариантом.
И CMake, и ndk-build имеют встроенные механизмы для импорта сторонних библиотек. https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html документирует подход CMake.
Механизмы ndk-build для этого в настоящее время не документированы (я только что подал https://github.com/android-ndk/ndk/issues/998, чтобы напомнить себе, чтобы это исправить). Это довольно просто, хотя:
Вы отправляете каталог со следующим макетом:
mylib
├── Android.mk
├── include
│ └── mylib
│ └── mylib.h
└── libs
├── arm64-v8a
│ └── libmylib.so
├── armeabi-v7a
│ └── libmylib.so
├── x86
│ └── libmylib.so
└── x86_64
└── libmylib.so
Ваш Android.mk будет:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := libmylib
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/include
LOCAL_SRC_FILES := libs/$(TARGET_ARCH_ABI)/libmylib.so
include $(PREBUILT_SHARED_LIBRARY)
Ваши пользователи затем установят ваш пакет в какую-то директорию пакета (для этого примера $PACKAGES
) как $PACKAGES/mylib
. Затем они будут использовать это в своем Android.mk:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := libfoo
LOCAL_SRC_FILES := foo.cpp
LOCAL_SHARED_LIBRARIES := libmylib
include $(BUILD_SHARED_LIBRARY)
$(call import-add-path,$(PACKAGES))
$(call import-module,mylib)
Если вам требуется поддержка других систем сборки, обратитесь к документации по ним.
Вы, вероятно, заинтересованы в подписке на https://github.com/android-ndk/ndk/issues/916. В настоящее время я работаю над тем, чтобы упростить распространение пакетов NDK, это только в стадии разработки.