So, it’s been quite a while since I last posted on this blog. I’ve been pretty busy the past few months with various things. At work we had an important milestone during that time, which thankfully passed with flying colors. Outside of work though, I actually got married a couple of months ago! My wife and I eloped to Hawaii, just the two of us, and tied the knot. 🙂
So it’s been quite a busy period recently for me. Starting on vs-android back in January probably wasn’t the best timing. Getting it done wasn’t too bad; it was more the follow-up support email period that was tougher to deal with. More so, given the marriage preparations and what have you, which I was going through at the time. So vs-android got left by the wayside a while, and rightfully so!
A couple of weeks ago though, I picked up the project again. I was determined primarily to fix the dependency issues the previous version had. After looking again at what Microsoft had done with their Win32 toolchain, I decided to massively change my approach. I went from a system that was built primarily with MSBuild, with a little C# to sanitize pathnames and switches. To a system which had almost all of it’s moving parts in C#, with MSBuild just ferrying the project data into it.
That was pretty much the basis for the latest iteration of vs-android. I bolted on a few other things along the way, but for the most part it was just about getting it into a stable and reliable state.
So yeah, I’ve just wrapped up a new version of vs-android. I didn’t bother posting about the last couple of version revisions I did in the past, but this one is a little different. It got a pretty major overhaul. In my eyes has moved from an experimental toy, to something people can actually write production code with. So this is why the version number jumped up to point-nine.
To get an idea of the extent of said overhaul, here’s a list of the changes made:
- Verified working with Android NDK r5b, r5c, and r6.
- Much of vs-android functionality moved from MSBuild script to C# tasks. Similar approach now to Microsoft’s existing Win32 setup.
- Dependency checking rewritten to use tracking log files.
- Dependency issues fixed, dependency checking also now far quicker.
- Android Property sheets now completely replace the Microsoft ones, no more rafts of unused sheets.
- Property sheets populated with many options. Switches are no longer hard-coded within vs-android script.
- STL support added. Choice between ‘None’, ‘Minimal’, ‘libstdc++’, and ‘stlport’.
- Support for x86 compilation with r6 NDK.
- Full support for v7-a arm architecture, as well as the existing v5.
- Support for Android API directories other than just ‘android-9’.
- Separated support for ‘dynamic libraries’ and ‘applications’. Applications build to apk files.
- Response files used in build, no more command-line length limitations.
- Deploy and run within Visual Studio, adb is now invoked by vs-android.
- ‘Echo command lines’ feature fixed.
- All support SDK/libs (NDK, SDK, Ant, JDK) are okay living in directories with spaces in them now.
- All bugs logged within Google Code are addressed.
So yeah, quite a few of ‘em…
I think my favorite out of the lot was fixing up the property pages. Previously they looked like the below, with one specific page for Android’s gcc, and several other pages related to the Win32 compiler. Unfortunately while most of the Win32 settings were unused and benign, some of them (preprocessor, include paths, etc…) actually did do something. It was a little messy:
For comparison, here are the new property pages in the next image. All the properties now pertain to the Android build, no chaff in there at all:
So that’s a little taster of what has changed.
How much faster?
As a result of moving the dependency checking to using Microsoft’s tracking-log files, and also running gcc just once rather than twice to grab dependency headers. vs-android v0.9 runs significantly faster than it’s predecessor.
It wasn’t much of a slouch before, at least compared to the stock ndk-build scripts Google provides. In my previous blog post I looked at the speed differences, here’s the comparison with the v0.9 numbers added:
|ndk-build||vs-android v0.2||vs-android v0.9|
|Incremental Build (1 cpp changed)||1m24s||35s||23s|
|No-op build (build with nothing changed)||1m2s||0s||0s|
|Single cpp build, aka Ctrl-F7||N/A||2s||2s|
You can download the latest version of vs-android at my Google Code page, here:
What’s next for vs-android?
My plan going forward will just be to focus on any bug fixes needed. I have a huge laundry list of features I’d like to add, but I have to be realistic. I’ll likely put in a few smaller additions in incremental updates before I hit v1.0. In my eyes v1.0 will have an installer, and a “New Project Wizard”; anything else I manage to add to that is icing on the cake.
However, for the immediate future I’ll be trying to take a break from it for a while. What I enjoy most about coding is tackling various different problems. I get a little tired working on the same area of a project for too long, and vs-android certainly isn’t a project with a varied wide scope of tasks.
I’d like to go finish fixing up the CRTC syncing in XNACPC next, I think. I also had audio functioning last time I was working on it, but my dodgy CRTC code was making it sound pretty awful. 🙂 I’ve nothing fancy at all planned for the emulator, I just want to get the basics solid and throw up the C# source.