MacPorts After Mavericks


You’ve finally upgraded your Macbook pro to Mavericks. Sure the other kids have been slinging the fancy new OS for a while now but you’ve been a straggler. You wanted to make sure the water was indeed safe before toe dipping. Maybe you’re just cautious, maybe you’ve been down this road before and bitten. Whatever the case, hey there! I’m Cliff. You’re here because one of your command line tools suddenly stopped working. I’m here because I just fixed it for you. Read on to find out what you should do after taking on Mavericks on your trusty silver laptop.

Say you’ve typed the name of a command you were using last month which was called… oh I dunno, asciidoc. Go ahead, say it… right now, audibly. I’ll wait… Did you say it? Of course you didn’t because that would be a ridiculous thing to do, especially at X o’clock during your work day/personal time after performing the Google search which landed you on this page.  Here you are just looking for an answer to why your command line isn’t giving you the respect that Aretha Franklin demanded back in 1967 and here I go sitting on standby waiting for you to make a goon of yourself by speaking out loud to absolutely nobody. We could go on like this for ages or I could just get to the point and say what I set out to say. Now what was I saying??? Oh, right! Say you have just typed the name of… [wait I already said that] say you just typed asciidoc into your terminal and say the terminal was like, “Whaaa? I don’t understand your French, cousin!” Now why would your terminal respond that way? I mean it’s not like you are actually related to the terminal or anything. It’s just a program, rather a collection of 1s and 0s spinning on your magnetic disk… unless you have a solid state drive. (Don’t most people have SSDs these days?) Then for you and these 1s and 0s to be actual cousins would mean that your parents were somehow siblings and since the parent of most computer programs is some hacker with bad hygiene one might assume his siblings have similar hygiene problems which, though possible, would lessen the probability of pro-creation leading to your birth.

I had a point somewhere about one or two sentences back but now I’m a bit lost. Where was I? Something about your terminal acting all confused like, “whaaa…?” wasn’t it? Okay, now say your terminal was like “whaaa…?” and you were all like, “you know, ‘asciidoc’!! Now gimme my converted output!” And then the terminal was still like “whaaaa…?” How does this happen? I mean, you were just speaking “asciidoc” in all of its PDF flavors a month ago and now it’s like your terminal doesn’t even know you despite the fact that it refers to you as a cousin, implying some sort of biological relation. It just doesn’t make sense… your binary flesh and blood acting like a random citizen from another country. Here’s where it all went wrong.

Mavericks Upgrade

After upgrading to Mavericks software installed with MacPorts stops behaving. The simple solution is to reinstall MacPorts. The best way to do this is to run “Xcode-select –install” from your terminal which will trigger an install/update of the Xcode Command line tools. This is important because MacPorts still thinks the tools it used before the upgrade (like /usr/bin/gnutar) are available. After reinstalling the tools you should reinstall MacPorts using the binary package which will see the upgraded command line tools. Read how to migrate MacPorts here. After upgrading your command line tools and reinstalling MacPorts you and your terminal will be on speaking terms again. Thanks for stopping to read my foolishness and remember to tip your waiter… because if you don’t tip then the waiter leaves nasty stuff in your food and stuff. That nasty stuff leads to diseases like foot and hand-mouth disease. I don’t know if that’s a real disease or not, its something that my father in law complained to my wife about when she was younger. She’s older now and has never caught foot and hand-mouth because she leaves nice tips. The waiters sometimes smile at her too, though I don’t necessarily think it’s because of the tips. I think they smile at her because she has a nice smile. Speaking of her smile, don’t forget to run your system updates after the Mavericks upgrade because apple has other fixes for you. I don’t really know what that has to do with my wife’s smile. It seemed related when I first typed it but now it just looks silly. My whole post is silly and probably hasn’t helped anyone. I’m rambling because I’m on my 3rd cup of coffee today. I should just stop typing now. Did you tip your waiter? I’m just sayin’…

Learning Android Gradle Unit Testing


The Gradle build system is pretty robust and it is becoming mainstream. That means it behooves you to start putting it to use. I’d been spending a little time with various Gradle based projects and realized that there were a couple of things missing… documentation on the Android plugin. Sure you can look here but I’m a rebel and I like to pretend there isn’t any documentation while learning the hard way. Hi, I’m Cliff. You’re here because you don’t read documentation. I’m here to show you how to reverse engineer your own documentation using Gradle/Groovy goodness. Today’s article is going to be short since it only covers a small area.

So I’m playing with a Gradle based Android project trying to get unit testing to work when I hit a snag. I had been so used to Maven and following all of the popular Gradle documentation online will have you believing, “Hey this works mostly like Maven!” In fact, a basic Java Gradle project is mostly indistinguishable from a Java Maven project from the outset in that they both follow the same familiar structure. Just drop your compile files into “src/main/java” and your test stuff into “src/main/test”. You hardly have to write any code in your build file to work with these types of projects. So it is almost a given that I get lost when I opened my new Gradle-based Android project and tried to add unit tests. Let’s start from my first sign of trouble in Android Studio. My initial step was to create a test folder for my project to begin adding tests to. Doing so I noticed it was colored manilla-tan and not green as I’d expected. Now in IntelliJ there’s a nice little right-mouse context menu that allows you to mark a folder as either a source directory, a test directory or a resource directory. Right clicking in Andoird Studio did not reveal the same feature so I thought there was a bug in the recent Canary update. (“Doggone Canary bleeding edge!”, is what I murmured to myself in disgust.) Then I thought I could just edit my Gradle build file to get the proper color on my folder allowing me to right click tests and run them directly.

I copied a source set config from an earlier Ant-based Android project that I coerced into Gradle. In this project I used the sourceSet configs to map the legacy Android-Ant structure into something Gradle could work with. This was done many months ago and several changes to Gradle and Android has happened since then but I figured it would still work the same since the original project was still functional. Dropping the following under the android config in my build.gradle did not change the color:

sourceSets {
    test {
        java.srcDirs = ['src/test/java']
    }
}

Out of frustration I poured through all the Gradle documentation I had. Unfortunately I was reading Gradle docs and not Android plug docs for Gradle so I was confused into thinking what I was doing should work. Just before complaining on StackOverflow or filing a bug report I found a little hack I could use to debug my build.gradle. Remembering that a Gradle build is just Groovy source code gave me relief as I could just drop a println anywhere and inspect build elements in my console. (I use the terminal plugin in Android Studio so I didn’t even have to leave myIDE to try it.) I looked up the SourceSet API and then coded the following:

android.sourceSets.each {
    println "Sourceset: ${it.name} java source: ${(it.java ? it.java.srcDirs.join(':'):'Null')}"
}

That’s when it became apparent that there is not test source set in the Android plugin, only an androidTest sourceSet! I also learned, as I had figured, that there was no need to code an explicit source set so long as I followed whatever the convention was. I finally decided to write this blog post out of frustration because NOWHERE IN THE INTERNET UNIVERSE IS THERE ANY DOCUMENTATION EXPLAINING WHERE ANDROID TEST SOURCE LIVES!!! HOw frustrating it is to be an Android developer these days!