Building for Android using NDK not supported on Windows hosts

[chibicitiberiu]

I am trying to integrate Crypto++ in an Android project in Android Studio. The NDK component of my project is built using cmake, so I'm trying to integrate CryptoPP in the build process using CMake's ExternalProject_Add.

Our requirements are that we can build for Android using Windows as a host OS, and the current android setupenv-android.sh doesn't support Windows hosts.

I have built a python script which does most of the stuff in setupenv-android.sh here (some things are missing). The advantage with python is that it's cross platform, unlike bash.

[noloader]

Thanks @chibicitiberiu.

Yeah, the setenv-android.sh script is at end-of-life. It was OK for earlier NDKs when working on Linux using GCC, but it is mostly obsolete now. Worse, if you try to use it for a modern NDK with Clang it is just about completely broken. And it is duct-taped together for GCC, which is barely clinging to life.

@mouse07410, @MarcelRaad, @denisbider, what do you guys think? Should we let the original setenv-android.sh die and take @chibicitiberiu's new one? I think the two core questions are (1) is the license agreeable with public domain code; and (2) should we make Python a requirement for this corner of the library? (The rest are implementation details which @chibicitiberiu has mostly solved).

[chibicitiberiu]

I know that you had some issues with CMake before, but that is another option for Android which might integrate better with Android's build system (in the last few NDK versions, they moved to cmake as well).

If you don't want to add a dependency to Python, another option would be to try to make the setenv script part of the makefile.

Regarding licensing, I didn't really understand what you meant. Are you referring to the python script I linked? I can add a 'license' header to put it in public domain, if needed.

[mouse07410]

1. Yes, the header should be added, explicitly placing the script in public domain.

2. Making Python a requirement for the Android build should be ok. I personally don't mind requiring it for everything else (after all, that's what Botan does), but not sure what others would say.

[chibicitiberiu]

I added a license header to the gist, so anyone can use it freely.

[noloader]

@mouse07410 ,

Making Python a requirement for the Android build should be ok. I personally don't mind requiring it for everything else (after all, that's what Botan does), but not sure what others would say.

Yeah, I like Botan's use of Python. As far as build systems go I think Jack is the only guy who got it right. His stuff "just works" everywhere. GNU Make is a close second, but I think it falls short of Botan and Python. Autotools and CMake are a mess and don't compare.

GCC sees similar suggestions on occasion (switch from shell to Python). Apparently there's a problem with early Python and some of the regex'ing they do for targets. I don't think it would materially affect us, however.

[noloader]

@chibicitiberiu, @mouse07410, @MarcelRaad,

I think we can merge a PR if you guys OK it. I know the Android bits but I don't know Python. My lack of Python skills is why we have not used it in the past. (I'd like to cutover iOS, too).

[mouse07410]

No objections. In fact, I might offer a little bit of help with Python.

…

Sent from my test iPhone

On Dec 23, 2018, at 08:45, Jeffrey Walton ***@***.***> wrote: @chibicitiberiu, @mouse07410, @MarcelRaad, I think we can merge a PR if you guys OK it. I know the Android bits but I don't know Python. My lack of Python skills is why we have not used it in the past. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[noloader]

@chibicitiberiu,

I'd like to look over the script. Can you make a pull request? Drop it in TestScripts. Delete all of the previous setenv-android-xxx.sh scripts.

[noloader]

I think we can close this. We have working Application.mk and Android.mk.

I like @mouse07410 idea of porting to Python. Python should support Linux and Windows (modulo things like broken I/O between Python2/Python3). But I don't have the time to do.

If someone can port some of these scripts from Bash to Python then we can add them here.