New Gradle build system for Android platform


#21

FWIW, I just noticed you are not using the latest bundled CMake version available. I have also just performed a quick search on Google and found other having quite similar problem as yours using that same old bundle version.


#22

I installed the latest , 3.12.0
Still having the same errors .

CMakeError.log output :

Determining if the C compiler works failed with the following output:
Change Dir: C:/GAME-ENGINES/Urho3D-gradle-kotlin/android/urho3d-lib/.externalNativeBuild/cmake/debug/armeabi-v7a/CMakeFiles/CMakeTmp

Run Build Command:“C:\Users\bea034\AppData\Local\Android\sdk\cmake\3.6.3155560\bin\ninja.exe” “cmTC_13e0c”
[1/2] Building C object CMakeFiles/cmTC_13e0c.dir/testCCompiler.c.o

FAILED: null C:\Users\bea034\AppData\Local\Android\sdk\ndk-bundle\toolchains\llvm\prebuilt\windows-x86_64\bin\clang.exe --target=armv7-none-linux-androideabi --gcc-toolchain=C:/Users/bea034/AppData/Local/Android/sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64 --sysroot=C:/Users/bea034/AppData/Local/Android/sdk/ndk-bundle/sysroot -isystem C:/Users/bea034/AppData/Local/Android/sdk/ndk-bundle/sysroot/usr/include/arm-linux-androideabi -D__ANDROID_API__=17 -g -DANDROID -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -mthumb -Wa,–noexecstack -Wformat -Werror=format-security -fPIE -o CMakeFiles/cmTC_13e0c.dir/testCCompiler.c.o -c C:\GAME-ENGINES\Urho3D-gradle-kotlin\android\urho3d-lib.externalNativeBuild\cmake\debug\armeabi-v7a\CMakeFiles\CMakeTmp\testCCompiler.c

CreateProcess failed: The system cannot find the file specified.

ninja: build stopped: subcommand failed.


#23

Based on the log, you were still using the same old version. Currently I don’t think Android Plugin (at least not the version we are currently using) is capable of using vanilla CMake provided by cmake.org. Android plugin can only use the Android SDK bundled CMake. I supposed they do so because they have forked and modified the code which are not made available upstream (yet). I am not exactly sure.

Thus, you have to use the SdkManager to update your bundled CMake version and try again. Good luck.


#24

You are right , I thought it was using vanilla CMake ,
I updated to latest CMake using the SDKManager , still getting these errors .
I will try to debug it during the weekend .

Determining if the C compiler works failed with the following output:
Change Dir: C:/GAME-ENGINES/Urho3D-gradle-kotlin/android/urho3d-lib/.externalNativeBuild/cmake/debug/armeabi-v7a/CMakeFiles/CMakeTmp

Run Build Command:“C:\Users\bea034\AppData\Local\Android\sdk\cmake\3.6.4111459\bin\ninja.exe” “cmTC_43c9e”
[1/2] Building C object CMakeFiles/cmTC_43c9e.dir/testCCompiler.c.o

FAILED: null C:\Users\bea034\AppData\Local\Android\sdk\ndk-bundle\toolchains\llvm\prebuilt\windows-x86_64\bin\clang.exe --target=armv7-none-linux-androideabi --gcc-toolchain=C:/Users/bea034/AppData/Local/Android/sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64 --sysroot=C:/Users/bea034/AppData/Local/Android/sdk/ndk-bundle/sysroot -isystem C:/Users/bea034/AppData/Local/Android/sdk/ndk-bundle/sysroot/usr/include/arm-linux-androideabi -D__ANDROID_API__=17 -g -DANDROID -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -mthumb -Wa,–noexecstack -Wformat -Werror=format-security -fPIE -o CMakeFiles/cmTC_43c9e.dir/testCCompiler.c.o -c C:\GAME-ENGINES\Urho3D-gradle-kotlin\android\urho3d-lib.externalNativeBuild\cmake\debug\armeabi-v7a\CMakeFiles\CMakeTmp\testCCompiler.c

CreateProcess failed: The system cannot find the file specified.

ninja: build stopped: subcommand failed.


#25

I am sorry to hear that. I only have Win7 VM and am now trying to get the newly downloaded Android Studio IDE installed there and see whether I can reproduce your issue. To be honest, I would not expect it to differ from Linux host system by too much.


#26

I am able to reproduce the issue! It was caused by this line:

add("-DANDROID_CCACHE=${System.getenv(“ANDROID_CCACHE”)}")

In my setup on Linux and also in CI, I always have “ccache” made available. There is no ccache on Windows. It is anyway a mistake on my side to have that option always defined. I thought define it to “” is equals to not define it. I was wrong apparently.

Thanks for reporting this.

I also found another mistake in the path handling which causes the “Gradle sync” to fail on Windows system. In Windows the path separators are going the wrong way compared to *NIX.

I will try to fix these mistakes tomorrow.


#27

Those two issues should have been fixed in my local branch. However, I delay the push as I want to also fix one more other minor issue which causes the initial gradle sync on Android Studio to temporary fail, even on Linux host system, until a build is made and then the retry of gradle sync would become ok. CLI user does not have this last issue as initial “gradle build” from scratch will always work. I hope to get the initial “gradle sync” to work cleanly too.


#28

Made another push to the dev branch. Tested it to be both working on my Linux host system and on my Win7 VM. Here are roughly the steps I took on Windows system:

  1. Check out the branch.
  2. Prep the asset dirs in both the modules, i.e. change the Linux symlink to Windows MKLINK. Call git add to stage the changes, so that git won’t bother with them afterward.
  3. Set the gradle property to disable “URHO3D_LUA”.
  4. Open the project root in the Android Studio IDE. Accept the default to import the Gradle project.
  5. After the “gradle sync” completed without any error, press Ctrl+F9 to build the project or Shift+F10 to run the launcher app.

To enable Lua/LuaJIT, the “ninja” build tool must be installed globally. The reason for this has been explained in my previous comment above in this thread. Lua needs a host tool to be built alongside.


#29

It looks much better now , but fails during the actual compilation.

[138/922] Linking C static library Source\ThirdParty\ik\libik.a



The command line is too long.
ninja: build stopped: subcommand failed.


#30

Yeah, windows have quite limited command line size AFAIK


#31

Try use a shorter directory name.

Another way to workaround the Windows “cmd” limitation is to tell CMake/Ninja generator to use “response files”. This workaround is currently used by our MinGW build on Windows host too, I believe. However, this way would slow down the build due to extra disk I/O. I will see how many users request for it before deciding to implement this.


#32

The dev branch has been merged to master branch just now.


#33

Are we to expect an update to Urho3D official build documentation for Android or does the current one suffice for this case?


#34

It is already updated. Let us know if it is still not clear.


#35

I’ve seen it, sorry I forget to select the HEAD option for the documentation.

Thanks


#36

I’m on Win10 and I’ve hit the “The command line is too long” error @elix22 encountered also. If this is going to be an issue with windows build I think it would be better to have the “response files” option implemented.

Besides the earlier mentioned and shorter directory name, which other work arounds are available?


#37

I tested the Android build system on Ubuntu 16.04. Seemed to work, altough I notices that when I open the sample applications on actual device, they close immediatelly without giving any error message. This doesn’t happen all the time tho.


#38

Thanks for your feedback. Personally I have tried it on Windows 7 host system and all went well. I didn’t intentionally shorten my directory name or anything but I guess I was just lucky that the generated ninja build scripts did not exceed the command line buffer limit. Personally I think it is better to workaround by choosing a shorter project directory name than having forced to use “response files”. Also see https://github.com/android-ndk/ndk/issues/397.


#39

Any error from logcat?


#40

Didn’t yet looked in to that since I don’t have configured Android workspace locally, I used prebuilt docker images to run builds. Can check that later at home.