Fetch Qt instead of require it to be preinstalled

[Vertexwahn]

If you want to use those rules you have to install Qt on every developer machine and configure your CI to pre-install Qt. For instance, when using Azure you have to do something similar as described here

The requirement of a pre-installed Qt version is really anyoing.

Get rid of this!

Fetch a pre-build version of Qt via Bazel.

[justbuchanan]

This is a good suggestion, thanks for filing it. There are some pros/cons to each approach, so I think it would be good to aim for supporting both.

A few thoughts:

• If the bazel rules handle qt, we have the option between static and dynamic linking.
• If we dynamic link, the rules can download pre-compiled libraries that bazel-built binaries will link against. This will work as long as you're running your binary from the same project directory / computer, but if you distribute the binary to someone else, they need to have qt installed.
• If we static link, I think the only option is to build qt from source, which I haven't done recently, but assume is very slow. Bazel will cache the results, so maybe this isn't too big of a problem since you hopefully only have to compile it once.
• Assuming there's no way to download pre-built qt static libraries, we need to write a BUILD file for building ~all of qt or use something like https://github.com/bazelbuild/rules_foreign_cc.
• Static linking also brings in some additional restrictions according to the license
• static linking = bigger binaries

Ideally, I think it would be nice to provide two options with rules_qt:

1. bazel downloads qt source, builds it, and statically links it into your app
2. bazel uses system-installed dynamic libraries

[Vertexwahn]

I created an experiment here using Qt6. The idea here is to use a prebuild version of Qt and use dynamic linking.

[jheaff1]

FYI I’ve started working on a rule set like bazel_rules_qt that builds qt from source.

https://github.com/jheaff1/rules_qt/tree/build_qt_on_linux

It’s still very much a work in progress

[gedalia]

maybe there's a middle ground? Our system has a prebuilt qt that we grab for CI. It looks like BAZEL_RULES_QT_DIR env allow me to override the default include path. But not the moc path or the libs directory, is there any reason why that couldn't be pushed through the rest of the system? That would at least provide a workable way to build the package portablely.

[Vertexwahn]

Vertexwahn/rules_qt6 fetches on Windows and Linux a prebuild version of Qt6 - no need to preinstall anything - on macOS it is still required to preinstall Qt6 (brew install qt6) whit these rules.

It would be really cool if someone would mange it to build Qt from scratch with Bazel. That would eliminate all the prebuild/prefetch things and only build the necessary things. I see this as a long term solution.

A better short time solution would be to use aqt in a Bazel rule to install a prebuild version of Qt (and maybe brew on macOS if not doable with aqt). This seems for me most promising and doable in shorttime.

Preinstalling something should be avoided in my opinion. There might be users that have no idea of Qt or work on different systems (as I do) and do not want to repeat install instructions every time.

Also Bzlmod should be talken in consideration.

[jheaff1]

I’ve built Qt from source using Bazel and was in the process of making a rule set for it but sadly I don’t have time to work on it anymore

here is a branch that can build Qt for Linux using Bazel. I also have a messy private repo that can build Qt for windows and android. If people are interested I could make that public

https://github.com/jheaff1/rules_qt/commits/build_qt_on_linux

[jheaff1]

Aside from aqt, one could use this script to install qt without user interaction:

https://github.com/qbs/qbs/blob/master/scripts/install-qt.sh

[Vertexwahn]

@jheaff1 Did not realize that your rules work already on linux - would be nice if you share also the qt and android variant - maybe in own branches - not sure if I will ever have time to apply this to rules_qt6, but if someone wants to improve Qt Bazel support that direction does not sound to bad...