Please READ This If You Build Interface

We have merged PR 15510 that makes us migrate to Qt 5.12.3. This PR introduces a major change to the way we get Qt on dev machines.

We are now using our own build of Qt binaries and we provide them through VCPKG to developers during the initial steps of cmake like any other external library we are depending on.

You will need to:

  1. Clear your build folder AND your vcpkg folder.
  2. Remove the environment variable “QT_CMAKE_PREFIX_PATH” in order for cmake to understand that you want to use the vcpkg delivered version of Qt build by HiFi.
  3. Do a full cmake pass, vcpkg steps (downloading Qt there), and then you’re ready to build.
  4. Build.

EDIT TO ADD: You can keep using your own binaries of qt (now officially supporting 5.12.3) by defining the environment variable QT_CMAKE_PREFIX_PATH to the path of your qt binaries. Then cmake will NOT download the HiFi Qt, and will expect to find the Qt binaries from there.

The rationale for the change:

  • 5.12.3 resolves several recurrent bugs.
  • Our own binaries for Qt will provide better information from Backtrace.
  • One less external library to worry about – automatically taken care of by vcpkg.

Please email with any questions. Thank you!

1 Like

What is the license for your QT build and are you making the source for it available?

Are there any options to use your own QT Binaries if you have them? This is starting to get stupid that we have to keep using whatever VCPKG gives us when we have full development environments on the ready.

@FlameSoulis doesn’t like something that’s so unexpected .

You know what? Go ahead and try to build the damn client and server then. I’m so tired of your garbage with everything I say.

Also, some people were looking into doing special builds of Qt that includes codecs for Youtube support in Webengine. This change completely destroys this.

So yes, I wouldn’t like something this so unexpected. AND NEITHER DOES ANYONE ELSE WHO FOCUSES ON CUSTOM BUILDS!

Find a post you made where you liked somthing

I believe (but haven’t tried) that if you keep the QT_CMAKE_PREFIX_PATH then the build will use Qt from there instead of downloading the vcpkg version. … Unless, perhaps, if building PRODUCTION on Mac OSX.

I do custom builds, and I can’t say this feels like an awful burden. I’m also the (only?) person who has actually built a custom QtWebEngine that has proprietary codec support. Adding Qt to vcpkg doesn’t really interfere with this. I guess I’d recommend that if you’re treating vcpkg as a black box, to get to know how it works so that you can customize it to use your own Qt binaries.

Correct - edited to add this in original post. You can keep using your own binaries of qt (now officially supporting 5.12.3) by defining the environment variable QT_CMAKE_PREFIX_PATH to the path of your qt binaries. Then cmake will not download the HiFi qt, and will expect to find the qt binaries from there.

Building on Mac OSX does not change the above. :slight_smile:

We are using the Qt source code from their repository. Specifically we clone from this repo:
git clone --recursive -b 5.12.3 --single-branch

This code is published and licensed by Qt. For any questions about that license, please contact Qt.

We have made two small patches to that code to get it to work on a couple of platforms we target. These patches are small, and only really select different compile options from the Qt code. Those patches are published in our HiFi repository in github here:

Those patches are covered under our standard Apache 2.0 license.


Huh… indeed, those are some small patches. A bit confused with qFloat’s changes but eh, shouldn’t be that big of a deal. Many thanks for the quick response regarding the Qt stuff.

1 Like

This topic was automatically closed after 30 days. New replies are no longer allowed.