Urho3D 1.7 release pending work


#1

The topic of a new stable release came up in the C++11 topic Moving to C++11

For core devs: please list here all the pending work you’d like to complete before it.

JSandusky has some upcoming PR work that would include large changes (RakNet, compute support) so it’d be better to get this release out before merging those.

For me: I’d like to complete the pending library updates (Assimp, libcpuid), nothing else at least at this point.


#2

Would it be possible to have refactor-buildsystem merged in the main branch for the 1.7 release? I think the Android build-system improvements addressing these issues: https://github.com/urho3d/Urho3D/issues/1441 are working quite well.


#3

Just a note: though my list is exceedingly small and practically completable within days, I don’t mean that the release would need to be imminent, at all, but that we start moving toward it.


#4

I think this is mandatory per-condition of moving to C++11, according to


#5

@weitjong Do you think refactor-buildsystem could make it in this time in some kind of timeframe? Or if it’s too much work total still, maybe a cherry-pick of the Android toolchain changes + CI changes (and anything else which is nice to have and doesn’t wreak havoc)


#6

The commits that could be cherry-picked have already been picked in the last release. What left there have dependency on each other and should go in together. So, the question is, how much time it needs to get “completed”? That depends on how we define the complete. I have a few things in mind actually but have no time/commitment to carry them out. The good news is, that branch is always in compilable state. So, I could also say I don’t have any more plan and the branch is merge-ready after I have done a simple rebase tonight.


#7

We should probably fix the keyboard problem on the RPI platform before making a new release.


#8

Regarding the branch, that sounds good. I’ll let you be the final judge, but I’d vouch for merging it then.

I also hope to solve the constraint2D load/save issue.


#9

One thing to note though. The new Android toolchain has Android NDK r12b as the minimum requirement and it uses Clang compiler toolchain by default. But I think we have waited long enough. It is not a bleeding edge version anymore.


#10

Sounds reasonable. With NDKs, the worse problem is a new version appearing (while download of old is well hidden) and our build no longer working :slight_smile: Can give a test-spin of a Windows/Android compile of the branch, hopefully tonight.


#11

Current status for me on Windows: merging the buildsystem branch, installing NDK13b and running cmake_android resulted in the NDK’s Clang erroring on not finding various C++ headers, while it was building the Urho PCH.

In file included from D:/Lasse/Programs/urho3d-clean2/Source/Urho3D/Precompiled.
h:28:
In file included from D:/Lasse/Programs/urho3d-clean2/Source/Urho3D/Container/Ha
shMap.h:25:
In file included from D:/Lasse/Programs/urho3d-clean2/Source/Urho3D/Container/…
/Container/HashBase.h:32:
D:/Lasse/Programs/urho3d-clean2/Source/Urho3D/Container/…/Container/Hash.h:25:1
0: fatal error: ‘cstddef’ file not found


#12

I have not tested it on a Windows host yet. I will try upgrade to 13b in one of the Linux VM to see if the error can be reproduced there. And if so, then it is caused by newer NDK, which I believe has dropped GCC compiler toolchain all together. Our CMake/Android toolchain file still relies on the legacy GCC bits to be around, although it uses Clang already. Will check later tonight and report back.


#13

I had problem also with NDK 13b on Linux host system, although my build error was at an earlier stage. The problem was caused by NDK 13b changing the internal structure slightly for LLVM libC++ STL runtime. I will check in my tweak shortly. It builds fine afterwards on both NDK 12b and 13b. I didn’t test on Windows host though.


#14

Thanks! Will be sure to re-check then.


#15

The keyboard input problem on the RPI platform is now fixed in master branch. It was SDL bug all along.


#16

I want to finish work on my PR before 1.7
I’m going to close this PR when I ensure that dynamic resource path changing works correctly.
https://github.com/urho3d/Urho3D/pull/1832


#17

If there are no objections, by end of today or may be tomorrow the “refactoring-buildystem” will be merged into master branch.


#18

Great! I compiled the refactor branch now successfully on Windows / Android after installing NDK14. On NDK13b I got the earlier discussed va_args error from Clang while compiling. But since the newest works, I have no objections.


Unrecognized 'x86' specified in the ANDROID_ABI option
#19

Sorry for offtopic question but will latest NDK14 work on Android-4.0 ICS?


#20

Ok… It’s been a while. IK is in, RaycastVehicle is in. The Nuklear PR is still ongoing and will take some weeks, but don’t think we have to wait for that, as it’s kind of outside the “norm” for Urho features anyway, ie. no script support, and not completely flexible regarding resources.

There is the Retina Sierra fullscreen issue ( https://github.com/urho3d/Urho3D/issues/1917 ) which is kind of a bummer, but I don’t foresee at least myself having time to properly investigate it until mid-summer. There’s also a smaller Retina UI bug which makes UI textures bleed from the adjacent shapes, since the UI spritesheet does not have padding, but that’s easily fixable either by adjusting the trouble shape UV’s, or switching to nearest filtering.

So, might as well move on with the release by starting to compile the changelog. Any objections?