Allow skipping the detection of specific tools in qt.has_tools()

[nirbheek]

This has been an annoying problem because we are unconditionally checking for lrelease in qt.has_tools(), and that program is shipped in Debian/Ubuntu with (f.ex.) qttools5-dev-tools, which pulls in the kitchen sink (100+ packages, including GStreamer).

This is really annoying when trying to do CI builds of libraries or frameworks like GStreamer that use Qt but will never ship translations.

[eli-schwartz]

This feels generally useful I think, although I'm not sure whether it's better to take an optional list of wanted tools (defaulting to all of them) or a list of tools to skip.

[nirbheek]

although I'm not sure whether it's better to take an optional list of wanted tools (defaulting to all of them) or a list of tools to skip.

IME lrelease is the odd-one-out. The others are shipped with the same qtbase development package on all distros. I considered making this just qt.has_tools(lrelease: bool) but we'd need new kwargs if qt adds more tools in the future, and new kwargs have to be conditional inside a version check; so are harder for projects to start using.

[chubinou]

This feels generally useful I think, although I'm not sure whether it's better to take an optional list of wanted tools (defaulting to all of them) or a list of tools to skip.

in my #13304 PR , I proposed a patch with similar goals, I rather allowed to pass the list of tools to be check rather than opting out tools, this permit extending the tools without (I needed some QML specific tools) without having to require explicit opt-out from the user.

[nirbheek]

I don't have a strong preference between the two, maybe @jpakkane can help us decide between this and your commit.

[nirbheek]

In either case, the test in this PR is valuable and should be used.

[ferdnyc]

There's also the possibility of the tools having other names, like lrelease-qt6 or uic-qt5. (On Fedora that's how they're named in /usr/bin to differentiate, while each /usr/lib64/qt{5,6}/bin has both names.)

IME lrelease is the odd-one-out. The others are shipped with the same qtbase development package on all distros.

"Odd one out", maybe... but, again on Fedora, the situation is sort of the opposite. lrelease is in qt6-linguist or qt5-linguist which only requires qt{5,6}-qttools-common, a 0-dependency package. It's painless to pull in.

The others are, as you say, all in qt{5,6}-qtbase-devel which is a very large collection of "dev stuff". But all necessary to do anything with Qt development.

[nirbheek]

There's also the possibility of the tools having other names, like lrelease-qt6 or uic-qt5

That's fine, we are not talking about executable name on disk here, but about the tool's name.

[nirbheek]

"Odd one out", maybe... but, again on Fedora, the situation is sort of the opposite

Yes, which is why I didn't notice for so long. I run Fedora. I noticed this when I tried to setup CI for building an app that uses gstreamer in an Ubuntu docker image. Installing lrelease itself ends up pulling gstreamer somehow... completely ridiculous dependency tree.

[chubinou]

lrelease [...] It's painless to pull in.

when you build Qt yourself in a project, it's a bit annoying to be required to build tools you have no use for

IME lrelease is the odd-one-out. The others are shipped with the same qtbase development package on all distros

Issue is when you start adding support of other Qt tools, if I add support of qmlcachegen and qmltyperegistrar, this means that every people that are using has_tools will have a regression when updating meson as their code wouldn't blacklist these tools. we could restrict has_tools to only check for the current tools (moc, uic, lrelease) but then we would need another method for the new tools. By opting-in the tools you want to check, we can:

• allow has_tool to check more tools in the future (no regression when a tool is added)
• provide a list of default tools (so the default behavior remains the same as today)

In either case, the test in this PR is valuable and should be used.

Absolutely

[nirbheek]

@chubinou you've convinced me. I'll move the relevant things over to your PR from here (release snippet, test) and review your PR in the next few days.

[chubinou]

@chubinou you've convinced me. I'll move the relevant things over to your PR from here (release snippet, test) and review your PR in the next few days.

you may cherry pick my patch or rewrite it your way if you prefer, my PR may take some time to get merged

[eli-schwartz]

superseded by the linked PR, which is now merged.