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.
vs-android v0.9
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 | |
| Full Rebuild | 9m14s | 5m32 | 4m38 |
| 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 |
Download
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.
Comments
Hi Asaf,
– Yep, Properties directory is up now. Apologies that it was missing.
– The command lines are created programatically from the xml files which live in the ‘Props’ directory. It goes through each property in turn, and appends anything pertinent to that property to the command line. As goes the actual library and object dependencies, they’re fed through verbatim from what MsBuild gives me. Take a look at the GCCLink.cs’ GenerateResponseFileCommands() function. The ‘sources’ list would consist of the object files, plus any dependent static libs.
I can make a note to look into it, but if you think there’s issues with the library directory properties, feel free to post into the ‘Issues’ tab on the Google code page. It makes things easier to keep track of.
– Hmm, yeah it sounds like you may have to double up the configurations to do what you want: ‘Debug arm5’, ‘Debug arm7’, etc… I haven’t tried the ndk-build method of this you mention. Does it just end up with an armv5 .so in one directory, and an arm7 in another? It seems like setting something up like that could be pretty complicated with the way MSBuild works.
– I’ve not looked at WinGDB since February. I’ve got a few emails asking me about it since I released v0.9, but yeah I’m none the wiser as to whether it even works correctly with ndk-build/Eclipse setups. Let alone vs-android. I’ve heard mixed reports about both. Unfortunately looking into WinGDB is pretty far down my list. If someone else could look at it, that’d be great. 🙂
Thanks for the feedback!
Gavin.
Asaf says: Thanks. I was able to compile and even debug the task.
Just a small update regarding the link issues – I’m not sure if it’s the correct way to do so, but I turned on the ‘Use Library Dependency Inputs’ flag, which caused all the .o files to be linked together (instead of the .a files). Since I have all the code, and the projects for the static libraries are part of the solution, the link now works regardless of order (linking object files is apparently not order-sensitive).
As far as I know, the ndk-build script builds all the architectures which you specify in application.mk and places them in the correct libs/ folder. I’ll take a look at the problem later to see if I can come up with anything useful.
Thanks,
Asaf
Odin says: Curious how people prefer to debug on the NDK? Asaf, you mentioned you got WinGDB running? I’d be curious to see a walkthrough of it.
Hi Gavin.
Thanks for the new version! You’ve certainly made many improvements.
A few things for now:
– Can you please add the missing Properties folder and files to the SVN repository? I can’t build this project without them, and I want to play with the code a bit.
– I don’t know if you remember, but in my comment (in your previous blog post) I mentioned the link-order issue. We fixed it then by manually adding all the compiled .a files names to the linker command line. The new version somehow broke it, and we had to add a path to each file there (even if it’s a macro – $(OutDir)). Adding the path to ‘Library directories’ or ‘additional library directories’ (which add a -L””) did not help for some reason. Can you point me to the place in your code which builds the linker command line, or which at least creates the library dependencies list? Or even think of another solution?
– Another issue (I’m not sure it’s even solvable): Let’s say I want to compile my code to arm5 and arm7 (to support many devices but use the better instruction set when possible), and to several android platforms, and of course in debug/profile/release configurations.
Is there a way to do this without creating an exponential number of configurations? (in a similar way to the application.mk in which I only have to specify the eabi’s I want to support)
And a more general question? Does vs-android play nice with WinGDB mobile beta? I’m having problems using WinGDB, and I want to make sure it’s not because of vs-android.
Thanks a lot,
Asaf