Support for NixOS (and theoretically other non-FHS systems)

[lyssieth]

_{Terms: FHS}

Due to the unique quirks of NixOS, the include paths in /usr/include/{arch}/qt6 don't exist.

Instead, for development on NixOS, I use a flake that has project-specific dependencies. This generates some environment variables that could be used specifically on NixOS; QT_ADDITIONAL_PACKAGES_PREFIX_PATH seems to be the best option. Splitting this by : and searching for include/ folders within the provided directories would likely function well.

I wrote an experimental (but seemingly functional!) hack that allows it to work on NixOS at https://github.com/lyssieth/libqt6zig/tree/lyssieth-fix-for-nixos.

I've used it to test the basic example in the README and got it compiling and working just fine.

https://github.com/lyssieth/libqt6zig-nix-working

[rcalixte]

Hi! 👋🏼 Thanks for the interest!

Due to the unique quirks of NixOS

For this reason, direct support for NixOS was never planned. I've been a part of many projects where NixOS support was managed out of tree and any custom flakes or patches needed were handled with the infrastructure downstream by unaffiliated contributors.

However, on the roadmap to this project being contribution-ready, I am planning on supporting a Docker image that should assist development where needed. The resulting applications, assuming that the bindings/wrappers are compiled statically and with a dynamic dependency on Qt, will only have runtime dependencies on Qt, not unlike much of the existing Qt-based software ecosystem. Compilation would therefore be consistent and the resulting binaries would naturally assimilate with the existing ecosystem, hopefully resulting in simple packaging and/or distribution for applications that make use of this library. This also has a benefit of much simpler long-term support.

There is currently no ETA on when the Docker image support will be available as there are some other items on the roadmap that take precedence. In my mind's timeline, this and the related projects should be contribution-ready within a few months, including full Docker image support. This will be identified by the CONTRIBUTING.md file upload to the projects when the time comes.

Hopefully this helps!

[rcalixte]

I suppose for the time being I'll rely on my fork for my experimentation and development :>

Based on the differences, I don't think you should have a hard time rebasing. Just a heads up, there will be a few breaking changes in the short-term and I have some changes I want to make to the build.zig as well but I don't think these will pose any challenges for keeping your fork updated. For the breaking changes, the examples should reflect a decent approximation of what could be impacted for consumers.

[rcalixte]

Thanks for the detailed reply. I suppose for the time being I'll rely on my fork for my experimentation and development :>

I just pushed a change a few hours ago that will allow you to pass extra paths to the library at run-time. It takes a different approach to your implementation that used an environment variable and due to being native to Zig's build system CLI inputs, the delimiter is a comma if more than one path is desired. The README for the library and the examples have been updated with the option's usage as well.

While I hope this helps your use case, the only caveat is that this feature is being implemented for the other platforms that are on their way to being supported, namely macOS and Windows. The libraries that have been added with the extras- prefix mostly require local compilation which means that either a pre-defined set of paths were forced on consumers of the library or an option would be added to support those environments. I opted for the latter not only because I think it's a better overall experience but additionally because this could also aid consumers using CI/CD environments. I am labeling this a caveat because NixOS et al. are still unsupported and I don't want to mislead anyone or set inappropriate expectations. As long as those other platforms need this option, it will remain around. The current trajectory is that those other platforms will need this option and I am not aware of any significant efforts underway to change this.

The README excerpt:

In the event that one or more extra library include paths are needed e.g. a locally compiled extra library in a non-standard path, the extra-paths option supports this use case:

zig build -Dextra-paths="C:/Qt/6/mingw_64/include"

or

zig build -Dextra-paths={"/opt/qt6","/opt/lib/qt6"}

[lyssieth]

Sounds good!

Sadly, I ended up going with C++ instead for the time being. I am definitely going to keep following this project though, since I do prefer Zig.

[rcalixte]

Sadly, I ended up going with C++ instead for the time being. I am definitely going to keep following this project though, since I do prefer Zig.

Thanks for the update! Was it familiarity with C++ that pulled you or something that could be improved with this library that pushed you?

[lyssieth]

Thanks for the update! Was it familiarity with C++ that pulled you or something that could be improved with this library that pushed you?

Honestly the main thing was just... How rapidly I could get it working for me.

My skill level with C++ is maybe equal to mine with Zig, but in the end it really just came down to... could I figure out how to make thing do what I want quickly. And that happened faster with C++.
I'm probably going to give this a shot again sometime in the near future though; can tell you more when I know more.