You must have a working Qt 6 C++ development toolchain to use this binding. The Building section below has instructions for installing the required dependencies.
This might be a bit of a sticking point. The Zig ecosystem is (rightly!) starting to expect completely hermetic builds. It’s quite reasonable to expect an application to link system Qt during the process of packaging that application for that system, but during development, it’s a pain in the ass. On Windows, the concept of a development toolchain barely even makes sense.
Some alternatives to this are:
seizer (demo) - static executables that on linux speak wayland directly, or on windows call into the UI DLLs
I feel like people who grew up in the 90s (such as myself) still have a soft spot for “native UIs” but the appeal and definition of such things has weakened significantly, I think mainly because of the weight of the dependency of toolkits such as GTK and Qt, and the fact that they also drag in C++, like it or not. Heavy dependencies are not always felt or understood directly, but I believe the application landscape has quietly navigated around them.
It’s unfortunate. I think with some careful consideration, we could have landed somewhere in between that would be a sweet spot. For instance, an idea that I still want to explore is the idea of putting a native UI toolkit behind a stable server that the OS provides. Then applications could be minimal - they only have to speak the protocol - and they could be in any language.
We have Qt6 and Qt5 as well as all their dependencies packaged for and building with build2. So you can have a fully hermetic build on all the major platforms (including Windows) using any of the major compilers. It was a lot of work and required quite a few advanced features in the build system to handle without hacks.
Here is a crazy idea: we could hook build2 to the Zig build system which would give Zig immediate access to around 500 C/C++ packages we currently have. They are all fully hermetic in that they and their dependencies build with build2 uniformly across platforms. build2 is already a library, albeit C++, but it shouldn’t be hard to expose a C interface for a high-level build system driver API. Or we could just invoke it as a separate process.
This looks interesting. Did you use a tool to automate writing the bindings? How long did it take? Also, would it be possible to setup a GitHub action that generates the shared object files? I’m not sure if this is possible if the build takes more than 1 hour though.
The code to generate the bindings is included under cmd/genbindings. It’s written in Go since that is what the upstream was based on and it will likely stay that way so that bidirectional collaboration can occur for a toolkit as large and complex as Qt.
This… took a while. Various iterations, starts and stops, bouts of burnout, etc. etc. These libraries are far from complete and there’s tons more in the backlog that isn’t included in the release. There’s a few comments in the code for things I was trying and other in-progress pieces sprinkled throughout.
CI & CD are part of the plans for these projects and are kind of a hard requirement before code contributions can happen due to the large size of the code base. GitHub’s runners should be able to complete the build for these in under 20 minutes though the free public runners have a limitation of 4 vCPUs. That remains to be tested.
I don’t know if folks would want to consume object files from the repository or if they would rather receive them from their distro or compile them locally themselves. I tried to structure the libraries so that it would be easy for distro maintainers/packagers to pick up. I also think these are better as static libraries than dynamic ones since the development process will likely be very local/specific due to the Qt versioning variations available in the wild. I would love to hear what folks think.
This might be a bit of a sticking point. The Zig ecosystem is (rightly!) starting to expect completely hermetic builds. It’s quite reasonable to expect an application to link system Qt during the process of packaging that application for that system, but during development, it’s a pain in the ass. On Windows, the concept of a development toolchain barely even makes sense.
Some alternatives to this are:
I feel like people who grew up in the 90s (such as myself) still have a soft spot for “native UIs” but the appeal and definition of such things has weakened significantly, I think mainly because of the weight of the dependency of toolkits such as GTK and Qt, and the fact that they also drag in C++, like it or not. Heavy dependencies are not always felt or understood directly, but I believe the application landscape has quietly navigated around them.
It’s unfortunate. I think with some careful consideration, we could have landed somewhere in between that would be a sweet spot. For instance, an idea that I still want to explore is the idea of putting a native UI toolkit behind a stable server that the OS provides. Then applications could be minimal - they only have to speak the protocol - and they could be in any language.
We have Qt6 and Qt5 as well as all their dependencies packaged for and building with
build2. So you can have a fully hermetic build on all the major platforms (including Windows) using any of the major compilers. It was a lot of work and required quite a few advanced features in the build system to handle without hacks.Here is a crazy idea: we could hook
build2to the Zig build system which would give Zig immediate access to around 500 C/C++ packages we currently have. They are all fully hermetic in that they and their dependencies build withbuild2uniformly across platforms.build2is already a library, albeit C++, but it shouldn’t be hard to expose a C interface for a high-level build system driver API. Or we could just invoke it as a separate process.This looks interesting. Did you use a tool to automate writing the bindings? How long did it take? Also, would it be possible to setup a GitHub action that generates the shared object files? I’m not sure if this is possible if the build takes more than 1 hour though.
The code to generate the bindings is included under
cmd/genbindings. It’s written in Go since that is what the upstream was based on and it will likely stay that way so that bidirectional collaboration can occur for a toolkit as large and complex as Qt.This… took a while. Various iterations, starts and stops, bouts of burnout, etc. etc. These libraries are far from complete and there’s tons more in the backlog that isn’t included in the release. There’s a few comments in the code for things I was trying and other in-progress pieces sprinkled throughout.
CI & CD are part of the plans for these projects and are kind of a hard requirement before code contributions can happen due to the large size of the code base. GitHub’s runners should be able to complete the build for these in under 20 minutes though the free public runners have a limitation of 4 vCPUs. That remains to be tested.
I don’t know if folks would want to consume object files from the repository or if they would rather receive them from their distro or compile them locally themselves. I tried to structure the libraries so that it would be easy for distro maintainers/packagers to pick up. I also think these are better as static libraries than dynamic ones since the development process will likely be very local/specific due to the Qt versioning variations available in the wild. I would love to hear what folks think.
Super cool, I could see the C bindings to be used from Odin.