Using qt-pods to share your code

Adding dependencies to your project can often be very painful, because technically there are many ways to include foreign code.

In very simple cases you might just copy over code, in most cases you are going to link against a library and sometimes you have to compare whole feature sets of frameworks and make up your mind, if the implications imposed by that dependency are a good trade-off compared to the benefits.

From a developer’s perspective this is a nightmare. Usually you just want to add a certain ability to your app, whether it is to decode an audio format, communicate via SOAP, send mails, speak to a certain REST API or analyze images, or whatever you are in need of. Luckily, there is a guy on Github who did just what you need. Just imagine you could just click on a button and within seconds you would be up and running using his code. Scary? You might think so, but this is what qt-pods was designed for.

Calling qt-pods a package manager feels a bit odd, because this doesn’t describe precisely what it does. It is managing dependencies of your project via Git’s submodules. While Git submodules can be a tweaky thing in general and there are good reasons not to use Git submodules in all cases, qt-pods does its best to tell Git not to make any mistakes.

qt-pods works within a qmake’s “subdirs”-project template, that is a pool of projects aligned next to each other (well, technically you can tweak it not to be like that). “Pods” are being compiled into static libraries and are then linked against your target application. With a bit of .pri-magic (which is not magic at all, if you take a deeper look), pods can specify their own dependencies to the final app. As the pods are Git submodules, they are all independent repositories. That means, if you ever encounter foreign code to fail, you can fix it by yourself, but even better: you can generate patches or propagate these directly to the maintainer of the project. This is why the definition “package manager” fails, because what you actually get is not just an end product, a packaged result of some code, it *is* the code in a fully working environment. If included properly, the maintainer himself will include his code as a pod (from the same source like you, actually) and embed into a test project.

In order to get you started quickly, I sat down and defined fixed rules based on my previous experiences and then wrote an application that you can use to manage your pods. There is a graphical user interface and a command line version (which still needs some development).

You can find qt pods on GitHub and on qt-pods.org (deprecated).