LeanQt: a stripped Qt 5.6.3 that builds with BUSY instead of qmake

The motivation is a compiler and IDE that has to ship everywhere

LeanQt is a stripped-down Qt version which includes the essential features and is easy to build from source and to integrate with an application. The primary motivation was to make the author's Oberon compiler and IDE easier to compile and deploy on all relevant platforms with as few dependencies as possible. The reasoning about upstream Qt is worth reading because it explains the design. Qt 5 is described as an excellent framework that provides all the necessary features in a platform-independent way, and it has low requirements for the C++ compiler and is available virtually on all platforms where there is a C++98 compiler. But there has been a proliferation over the years in which Qt was bloated with features of questionable value, the standard binary installation is huge and requires a login to a commercial company server which discourages many people, and the official build is complicated with many dependencies and sometimes incompatibility issues depending on the operating system and the required Qt version. The development initiated with Qt 6 makes higher demands on the compiler and system. For an application using only the non-GUI part of Qt, or only basic GUI features, those are significant impediments.

BUSY replaces qmake, and the source tree is rearranged

The base is the code of Qt 5.6.3, chosen because it was the last Qt version available under both LGPL v2.1 and v3, and the repository ships the matching licence files, LICENSE.LGPLv21, LICENSE.LGPLv3 and LICENSE.GPLv3, plus an LGPL_EXCEPTION.txt. Instead of qmake the BUSY build system is used, and the author says that was one of the reasons he implemented it. The source tree is also different from the original toolkit, since a lot of the original subdirectories such as mkspecs and qmake are no longer required, and there are no longer separate subdirectories under corelib or gui, since each was depending on every other anyway. The tree in the repository reflects that rearrangement, with core, gui, graphics, widgets, itemviews, net, xml, concurrent, image, mime, tools, addons, includes, thirdparty and examples as the top level directories. There is also a missing.busy file, which is the mechanism behind the delete-and-still-build promise.

Minimal by default, features added with HAVE_x parameters

The inversion of the usual model is the point of the whole project. In original Qt everything is included by default and minimization takes a lot of work. In LeanQt the default configuration is minimal, and features are added on demand using the HAVE_x parameters, where x is something like THREADS, FILEIO, SSL or WIDGETS. You can even go further, because the author added configuration options that make it possible to use a minimal version even without the file engine and the core application, and many changes to the original source code were necessary to make that work. The API is mostly the same, so the original Qt documentation is still valid, which is the practical payoff for a codebase that used to be Qt 5 code. For someone porting an existing application, that means the migration is mostly about the build configuration and the module layout rather than about rewriting calls, and the module relocation table later in the readme is a list of what moved where.

Delete the directory you do not need, and the build still works

The tree does not have to be shipped in full. If an application does not need image or GUI support, the corresponding source code directories can be deleted. BUSY has a fallback mechanism for the case when a module is not present: if the image or net directories are deleted, BUSY loads the missing.busy file instead, and that placeholder acts as a stub for the missing modules and generates a build time error if an application tries to use them anyway. The thirdparty Readme file lists the directories that are potentially removable, so the list of what you can cut is written down rather than guessed. The value of this is in the final artifact. A tool that ships a small framework rather than a large one has a smaller installer and fewer platform packages to support, and for a project that must deploy to every relevant platform, that reduction in surface area is often the whole point.

What is in, and the long list of what is out

The available features are listed in the readme and read like a QtCore inventory: bytearrays, strings and unicode, data compression, localization and mime types, collections with implicit sharing, date and time with time zones, variants and metatypes, utf and latin codecs, an io device abstraction, the file engine, text and data streams, regexp, logging, md5 and sha1 hashing, geometry, json and url, xml stream with sax and dom, threads and processes, shared memory, application and command line handling, objects and events, the rcc resource compiler, the moc meta object compiler, libraries and partially plugins, synchronous and asynchronous networking, map and reduce with filter and reduce and async computation, image handling with format conversion, window handling with events and 2D bitmap and vector graphics plus fonts and rich text, a pdf and odf writer, the widgets and graphics framework, and the uic user interface compiler. The excluded list is the other half of the story. No support is planned for qmake, statemachine, codecs beyond the minimal set, animation outside the graphics module, dbus, sql, svg, nfc, bluetooth, multimedia, web and browser support, testlib, scripting, opengl, direct2d, directfb, qml, graphics effects, accessibility, wacom tablets, gestures, and the mobile platforms such as ios, android, winrt and blackberry. Printing, SIMD support and the Linux framebuffer platform are on the long term list.

Platform notes that will decide whether it builds for you

The readme carries specific notes that matter more than the feature list. All widgets, including the item and graphics views, work on Linux, Windows and Mac. The macintosh style does not fully work yet, with some display errors, so LeanQt starts with the fusion style also on Macintosh, and the mac style can be enabled manually by adding -style macintosh to the application command line. On Mac the generated executables must be included in an application bundle using a separate tool if you do not want a terminal window to open, or the menu has to be brought explicitly to the foreground by clicking the desktop and then the started application window. On Windows, MinGW works with static builds but not yet with shared builds, so HAVE_SHARED should not be used with MinGW on Windows, and Clang on Windows is not compatible with the current version, so MSVC or MinGW should be used instead. The author reports successful testing with different configurations on Windows x86 and x86_64, macOS x86_64 and M1, and Linux x86, ARMv7 on Raspberry Pi and x86_64. The project is not archived and the last push was on 2026-06-27, with the newest tagged work being the 2022-12-16 release noted as GUI feature complete.

Editorial conclusion

LeanQt fits a maintainer who ships a native desktop tool, wants to compile their own toolkit rather than require a commercial binary installer, and needs to strip the parts of Qt their application never touches, since the default configuration is minimal and modules are added on demand. It does not fit a team that needs a maintained Qt with a support contract and a current compiler toolchain, because this is Qt 5.6.3 code and the newest tagged work in the repository is from 2022. Before you adopt it, check the no support planned list against what your application actually calls, because dbus, sql, svg, multimedia, qml, opengl and accessibility are all excluded, and test on the compilers you intend to ship, since MinGW and Clang on Windows have documented gaps.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. rochus-keller/LeanQt on GitHub