This is the documentation for QBT, a build tool which specializes in dependency management and stitching repositories together.
Here are some frequently asked questions about QBT
Here is what makes QBT great!
QBT is released under the Unlicense. A locally hosted copy of the license is available here. The author's intent here is to spend as close to zero time units screwing with licenses while explicitly disclaiming and any all copyright monopoly interest.
QBT is small! The distribution of
meta_tools is only 12MB, and all you need to get started is that, a JDK8, and Git installed.
Python is also required to be on your path as the wrapper scripts that invoke qbt are written in python, but they should work with system python and no additional dependencies.
You can download a binary release of QBT from the QBT Website.
You, my friend, are our sort of crazy. Unfortunately, in its current state, QBT is not super easy to build without QBT (although nothing precludes us from producing a bootstrap script). If you just want to produce a copy of QBT which you are certain contains only artisinal jars you lovingly downloaded from maven central yourself, plus the source code, you can do the following:
(r, sha)in the
git init $r && cd $r && git fetch https://github.com/AmlingQbt/$r.git refs/qbt-pins/$sha && git checkout FETCH_HEAD
3prepo for a list of dependencies from which you could produce a transitive closure of dependencies. You will also see data in
mc/.cachethat contains the version fetched and the jars downloaded, you may elect to validate these jars by comparison to mavencentral instead.
qbt_manifest, or in a
qbt.versionTreefile (included in the distribution), build each “package” from the ground up by invoking javac with the classpath, then adding the resultant classfiles to the classpath.
qbt.QbtMain, setting the classpath as before and setting
JAVA_1_8_HOMEto a 1.8 jdk. From here, you can fetch and build a “real” qbt using your janky but verified qbt.
There are still a few outstanding questions with QBT, particularly in how organizations will share code externally with eachother. QBT's documentation is also very immature still. Aside from that, we believe QBT is ready for use inside an enterprise or for building personal projects.
Presently QBT is only well-tested on GNU/Linux. It should be very easy to make QBT run on any UNIX-like operating system, such as OSX. There are not presently plans to add support for windows, and windows users should probably plan on running QBT in a VM, however because QBT is written in Java it is possible it could work on windows some day.
There is a reason so many companies have written their own (internal, proprietary) build system. The reality of massive enterprise scale development is that many independent teams work across many separate repositories and create dependencies which span technological stacks and spheres of influence, but at the end of the day, a company wants to release tested, consistent versions of software to its customers (whether that means deployments of services or “shrinkwrap” style releases).
Existing solutions for building software are not, generally, able to span different technology stacks (how do you make a ruby gem that depends upon a python script, or a java program that depends upon a C library? How do you develop a framework that produces client APIs in java, python, ruby, and C/C++?), all because they are too coupled to the language they were designed to serve.
Existing solutions for building software are also not, generally, able to stitch together consistent views of software across many repositories, because they are not coupled enough to their source control system.
QBT is not exactly a build tool, so much as it is a dependency management and repository stitching framework in which you may use whatever other build tools you desire. QBT is fairly coupled to the Git source control system, though it could probably be adapted to any equivalent DVCS (such as Mercurial). QBT is completely unoppinionated, however, as to what a build actually means. You have some inputs on the filesystem, a script runs, and it puts its outputs somewhere else on the filesystem. QBT does not know or care if you are building shared object libraries, dynamic executables, wheels, eggs, gems, debs, rpms, tarballs, crystals, whispers, dreams, or magic spells, but if your
qbt_manifest says that one magic spell depends upon another, it will dutifully put its output artifacts on the filesystem so the other magic spell's build process can find them.
If you currently have every line of code you wrote and every line of code you depend upon checked into a single massive repository, and you have a single effecient process which, from a checkout of that repository, can produce deterministic build outputs, then QBT can't really help you (unless your build lacks incrementalism or parallelism, and you want to add that - it could help with that).
Since the above statement is true for almost nobody I've ever heard of or talked to, most large organizations could benefit from QBT.