Are there any plans to support any build system other than CMake and Cargo?
For what i can tell it's basically impossible to build cxx-qt using bazel out of the box, the problem seems to be the usage of the target directory as a shared location to export headers, while it works perfectly with cargo (i've been working on a prototype at work for quite a while) we're tied to bazel to actually produce production binaries.
If there's no interest to add bazel/buck2 support where do you think someone should start looking to add community support?
I've read the contributors guidelines but if anyone can give a couple pointers it would greatly appreciated.
I've already successfully added bazel support for version 0.2 of qtbridge but this project seems way more involved in code generation and interop between c++ and rust so i'm a bit lost
Activity
6
christian-belloni17d agoThanks for the reply, i'll start working on a third party crate then, for the time being it will be highly opinionated since from what i gather there aren't many project mixing rust and qt without using cmake/cargo.
Hopefully there wont be a need to make changes to cxx-qt-* crates but in case there will be could i open some pr's? I don't want to overwhelm you with pull requests for a feature that's not in scope of the project and we can maintain our fork if needed
ahayzen-kdab8d agoIf there are changes relevant to all build systems they would likely be accepted, but yeah probably build it out and see what is required or whether it can work via a wrapper / third party crate etc.
christian-belloni8d agoFrom what i encountered so far no changes needed 🥳, i'll leave a link to the wip repo if anybody else is interested
The only change that i can foresee is to be able to separate source generation and actually compiling, if it's something that could be accepted i'll start to work on a pr
ahayzen-kdab8d agoAwesome!
The only change that i can foresee is to be able to separate source generation and actually compiling, if it's something that could be accepted i'll start to work on a pr
Would it be enough to have another method on CxxQtBuilder similar to build but instead does not build and only does generation ? Eg pub fn generate(mut self) -> Interface {...} or similar as an endpoint to the builder pattern if you only want to do source generation / collect the initialisers. As this would likely be contained changed of one additional method to CxxQtBuilder and likely accepted :-)
christian-belloni8d agoWould it be enough to have another method on `CxxQtBuilder` similar to `build` but instead does not build and only does generation ? Eg `pub fn generate(mut self) -> Interface {...}` or similar as an endpoint to the builder pattern if you only want to do source generation / collect the initialisers.
Yeah, that's exactly what i was thinking
So far i have not seen any modern Qt projects that are not using CMake, as there are a load of helpers you generally use there, then the fact that a Cargo build for a Rust oriented build is more a bonus of how things work - and then most Rust projects mixing Qt are going to be Cargo. So to add official support it would need real world applications to be pushing this requirement, as we are targeting mainly existing Qt users migrating to / adding Rust to their existing Qt applications with this rather than starting from scratch.
However, before we thought it might be possible to create a CLI wrapper around cxx-qt-build like the
cxxbridge-cmdand use that for other build systems. But with all the options for different QML module export etc I don't know how complicated the CLI would be and whether it would be worth it, you also would need to support various different output artifacts like headers and object files for things to work with the calling build system. This could be something that could likely be experimented in a third party crate.