Latest question before going in a meeting to decide which engine use for our newer projects.
We release a lot of game for android using NDK i read in the forum someone that says we may use 15c.
I did a fast test using latest ndk and i got a clang.exe error, so i have to ask it.
Which version of ndk should be used?
The latest recommended approach for Android build is to use “embedded” NDK-bundle from Android SDK, instead of using standalone NDK.
Go with the latest version unless you need an old one because of some sort of backward compatibility.
Regarding this, I’ve used as old as 12b without problems.
I had a little problem with an already known issue… (cmd.exe command too long) but i guess i fixed it by manually change the build.ninja files.
It was annoying but necessary.
Basically when a string is longer than 7800 char i cut the string and save in a file in the same directory and leave at its place this kind of command:
POST_BUILD = cmd.exe /C azafix6.txt
This seems did the trick.
Just wonder how many places you need to patch it. IMHO, this is a bug in the CMake/ninja generator when it is generating on Windows 10 host system. The bug does not appear when it is generating on Windows 7 host system, i.e. it knows when to use the response file correctly. To make it worse, the Android plugin for Gradle uses its own embedded
CMake from the Android SDK and not the standalone
CMake installed on the host system. Thus, upgrading the latter does not fix this issue. Someone should log this issue to Google Android dev team or at least bring the attention to the dev who has the bright idea of forking CMake inside the Android SDK package.
There’s a renowned cmake bug on Android running since something 3.0x to 3.9 I think, I can’t recall exactly, but I can check my notes if you need. So there’s no escaping using embedded Android cmake, which, in turn, has got “optimized” for the platform so that it “overperforms”, for instance while building ninja/cmake, and… well you got the picture.
I can probably understand why they need to do that quickly at the time. It may seem to be a good idea to fork and fix the bug in-house and shipped it as part of their package. Hey, even we do that with our 3rd-party libs. The problem is, their CMake version appears to stay at 3.6.4111459 while the upstream has moved beyond that version with new improvement on its side too. Anyway, that’s not my point of bringing this up. My point is, their embedded (read “optimized”) CMake/ninja generator does not do its job well and they probably don’t know it yet.
Now I’m very much interested in how you did this cause I’ve been trying to get this same thing resolved for like ages.
Hope you don’t mind sharing the details? I would really appreciate
Here i am!
Well to be honest i don’t know yet, i was compiling it when i was in office friday evening and i went home.
I will let you know on monday if everythings went fine.
Anyway i’ll try to explain what the cause is and how we could do the fix (if mine did not work).
Basically ninja create some files named build.ninja those file try to call “cmd.exe /C (path)” where path is a long string.
What is the problem?
The problem is that cmd.exe can only handle 8192 char in 64 bit or 2100 and something in 32bit.
Microsoft suggest to use shorter name (fuck you microsoft) or use a txt file with the parameters on it as for example:
cmd.exe /c file.txt
So i did a very annoying job, i got every build.ninja file that was generated and manually scroll searching line longer than 7900 char.
I found that eventually those are 4-5 line per arm.
BE CAREFULL if you do this, modify only the line with cmd.exe.
There are other long lines but those has no any problem.
I cut off the text from there and create a txt file in the same path, and add the filename.txt where i removed the line.
I know it’s quite difficoult to follow, also i am not english native so this is even worst!
Let me know!
You don’t need to explain the root cause again because it is a known issue already to us. I just want to know how many places you need to patch it. If it is only a few of them and I can get a regex pattern to isolate them then I can probably cook up a post-cmake step *.batch file similar to what we have in “script/.bash_helpers.sh” to auto-patch the generated build tree. The thing is, I don’t have Windows 10 at home so I cannot get this information myself. I don’t work with Urho3D while I am at office.
I will tell you something more on monday, i wanna be totally sure that everythings works as intended.
I just realized the Android SDK Manager now provides a newer CMake version (22.214.171.12488404). Are you using the newer version already?
I checked for updates friday, so if they did not update in this 3 days i guess i have latest cmake.
Sure I’m asking
The command line length error of ninja on Win10 has had my head spinning for some months now. Getting it resolved would really be great
Unfortunately my method did not work. I am trying something else but i have a bad feeling about this.
We had an issue 2 years ago with android sdk, basically it did not update correctly and we got a lot of issue.
I have a clean computer here in my office i will install android studio from zero and try there.
We decide to use this engine so i have to let it works.
It can really be frustrating sometimes. I gave up for a while but will still return back. I need to explore the possibilities of games on mobile and my bias has been so heavy towards Urho3D.
We have to release a lot of games on 3d for mobile and for html5, honestly speaking this engine works very well on html5 in terms of performance and in size (less to download).
I don’t want speak too earlier but with new android (released march 2019) and some modification to the gradle settings of the engine ninja rules are changed a bit… I hope it will work correctly!