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 featuresets 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 flange 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 orchestrate 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), but they same reference to the same pod managing core: qt-pods-core. So, the qt-pods project uses qt-pods to manage itself. This is how both look like:
Learn more about qt-pods and get started today: https://github.com/cybercatalyst/qt-pods