jedisct1 / libsodium

A modern, portable, easy to use crypto library.
https://libsodium.org
Other
12.06k stars 1.72k forks source link

android build convenience changes #1139

Closed ReenigneCA closed 2 years ago

ReenigneCA commented 2 years ago

I cleaned up the android build a bit more (in my opinion anyway,) open to any suggestions for changes to this. There is now an android.sh script that will build all 4 android versions of the library. The output of the build is now laid out as such that: all include files are under ${PREFIX}\ include\ while library files are in ${PREFIX}\ lib \ sodium \ ${CMAKE_ANDROID_ARCH_ABI}\

I would have done this during my last commit but I used to take what the old scripts put out and then create a structure like this with symlinks but that seemed a bit hacky to commit into the repo. The android-build.sh script now detects if $PREFIX has already been set and only sets it to the default libsodium-android value if it hasn't been. The android.sh file has a commented out like that sets the prefix. So now to successfully build for android (using the stable checkout and these scripts as the current state seems to fail to compile for armv8?) just run ./dist-build/android.sh and libsodium-android will contain arm7 arm8 x86 and x86_64 binaries in a suitable format to use CMAKE to link against them. If you have a place where you put all of your ndk libs ou can edit android.sh to set $PREFIX to that location and you're good to go after running android.sh.

jedisct1 commented 2 years ago

What is being called "arch" becomes a little bit confusing: different values are now used to represent the same thing in -march and TARGET_ARCH. Would there be any issues reusing TARGET_ARCH for -march?

I'm also a bit reluctant to changing the installation layout, as the end result would be different from every other target.

This is okay when compiling a project only for Android, but in a cross-platform project, it's nice to have exactly the same layout as on windows, iOS, etc.

ReenigneCA commented 2 years ago

I just went with the mindset of leaving the scripts the same as much as possible and TARGET_ARCH was used only for setting the march variable in the individual android-arch.sh scripts and then the directory for the build layout. I'm happy to change this variable name, maybe ANDROID_ARCH_ABI?

I was actually just thinking about the layout as it doesn't make sense to me anymore. I was duplicating the kind of layout I saw in examples but it is far less convenient than a more normal layout. https://developer.android.com/ndk/guides/prebuilts has "LOCAL_SRC_FILES := $(TARGET_ARCH_ABI)/libfoo.so" as an example, but it makes a lot more sense to put libraries in a lib folder ala ${PREFIX}\lib\${CMAKE_ANDROID_ARCH_ABI}/libsodium.so this matches the way linux normally stores libraries and would allow someone to specify a library search folder using the appropriate ABI then add libraries ignoring the fact they're cross compiling. I believe this also would make it match the other architectures more closely than the current version wouldn't it? At least for linux and mac? I think it also makes sense to make variables for the lib and include folders in android.sh and then check in android-build.sh to see if they are set before using defaults. Basically making lines in android.sh for those variables just like the one for the PREFIX variable with the TARGET_ARCH_ABI variable assumed to be at the end maybe?

# uncomment below and change the install location(s) to where you keep your ndk libraries and includes
# export PREFIX=/some/custom/ndkdeps/dir/
# to override default behaviour uncomment one of the two below lines. if set LIB_PATH will be a specific path where library files
# will be stored. if set LIB_PATH_PREFIX will have a folder appended to it based on the target ABI for the specific compile.
#export LIB_PATH=${PREFIX}/lib
#export LIB_PATH_PREFIX=${PREFIX}/lib
#export INCLUDE_PATH=${PREFIX}/include

I could also add the above approach and leave the default layout exactly the same though I do think having folders with ABIs that match CMAKE would make sense. I just woke up and it came to me how little sense the proposed layout made as you'd have to specify a specific path for each ndk library. let me know your thoughts and I'll work on a new version.

ReenigneCA commented 2 years ago

A bit more digging and ANDROID_TOOLCHAIN_NAME in CMAKE matches arm-linux-androideabi-clang aarch64-linux-android-clang and x86_64-linux-android-clang these names would be more suitable for the folders inside the lib folder than just the ABI in case someone wants to use their normal lib directory for their android libs instead of a separate ndk lib folder structure.

To be honest I haven't been able to find anything about how users of the ndk normally arrange their library files. When I build the protobuf library for android say x86 it results in a folder i686-linux-android21 / lib / (lib files) which makes sense to me as well as you can set your prefix in CMAKE based on architecture and find your libs, but this doesn't match the normal layout of a unix lib folder which is one folder with architecture folders inside it and you have to specify the android version which may not be the same for all of the libs you want to use.

I want to do some more experimenting to figure out how smart CMAKE's find_library is. I think it should be obvious I'm not a build system person :P. That being said I think just adding the custom variables in android.sh probably allows for people to do what they want. The only issue is that the ABI variables are set in the android-arch.sh files so you can't reference them in the lib and include folder variables, or at least I don't know enough about shell scripting to allow for it.