-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use pre-built Qt on all platforms #11
Comments
Status Update:
|
An alternate solution is to use prebuilt Qt installers on all platforms. Would just want some instructions on what to do in CMake |
Can this be done via CMAKE calls to direct the Qt release pages? Unpack the binaries of what is needed to build the App. This would allow documentation around this process for how this is packaged vs the manual steps involved now. |
It's kind of coming full circle at that point. Qt + OpenStudio has been a very long journey. History, in order, as I recall it:
Considering the long convoluted history of this, I want to make sure we know what we are doing next and why, and consider the alternatives. I'd personally like to see if it's possible to revisit 5, things may have changed in the last 4 months. I'm also curious what @jmarrec thoughts are? Do we still need a custom Qt on any platform? Last I knew, controlling the version of OpenSSL in use was a huge pain because of different dependent libraries expecting different things. (OpenSSL distributions and finding the correct OpenSSL has been a difficulty with OpenStudio + dependencies for at least the last 5 years that I can recall). This is only compounded by the fact that OpenSSL recently changed their API, which broke various automated build processes and made various pain points for us linking to multiple versions of the same library. |
I think there's a way we could make conan qt for all platforms. That being said Qt is a beast, and requires some system libs to compile, and especially to build the chromium and webengine stuff. Plus, a debug build of conan qt takes 40 GB and a few hours to complete (and you might not even notice that a component of qt didn't build because of missing libs or the need for python 2.7 in your path before it breaks much later during linking of openstudio). Given the size ot the build and the number of options we'll never have prebuilt binaries on bintray. So I'm not sure whether that's a good idea given the need for documentation of the specific setup needed, first build time, and disk usage, plus long term maintainability. @lefticus does that still make you want to go this route? |
Thanks @lefticus. That is indeed a good recap of the history with Qt. A couple of things to mention as we consider options. AFAIK, the 3.x CLI doesn't have a Qt dependency so I don't think we should spend a lot of time getting Conan to build qt for 2.x support as we'll be making the shift to support 3.x in April 2020. The separated App could be maintained by other non-NREL users so having the easiest possible solution to use Qt would be optimal. My main question - is there a reason we cannot use the pre-built binaries from qt for the App? As a test, rather than building Qt from the source, I downloaded the pre-built binaries for osx (https://download.qt.io/archive/qt) extracted the contents, tar'd up the clang_64 directory, posted to s3 and changed CMake to use that tarball. This seemed to work for osx, although admittely, this was a test and not everything in the GUI was tested vs using source build qt. |
@tijcolem I need a clarification, since I don't know the current state of things, but yes I was involved with the removal of Qt from the CLI, so I agree no reason to spend time on Qt for the CLI. But this task is for the already separated Application, right? @tijcolem and @jmarrec I'm open to anything that makes sense, just wanted to make sure we were all on the same page re:history, since I think I'm the only one left who's seen what was tried in the past. @jmarrec Why did you go down the road of custom building Qt with Conan in the first place, instead of using the already supported Qt Conan binaries that are already up on bintray? https://bintray.com/bincrafters/public-conan/qt%3Abincrafters Is it worth just trying the standard qt-conan build again? My recollection is that it was OpenSSL that was the thorn in our collective sides, tied together with the OpenSSL dependencies from the http library that's being used in the CLI. |
The binaries on bintray don't have the options we need (like webengine). I also had found a few options I needed that weren't supported by the recipe so I had to open a few PRs to bincrafters. It's worth testing again to see it that's still the case (probably is) You probably know that already, but to locate binaries on bintray conan creates a hash of the So bintray willl not include all binaries possible for Qt, as it's got too many options and burns a lot of CI time to build and storage space on bintray. |
Another thing was trying to use same openssl as openstudio too. If you look at conan-qt build.py (used by CIs to build and upload binaries) they don't do anything special which means binaries on bintray use default options. See the conanfile.py now, you'll see that means that zero sudmodules are enabled: https://github.com/bincrafters/conan-qt/blob/5093f8dc85ee01cb8b6d1baac2698c4b276cc9ce/conanfile.py#L123 |
If we were to use conan-qt, we could fork it and upload the binaries we do need on our bintray though to eliminate the need for lengthy builds by consumers (using conan terminology, here meaning us developers trying to build openstudio and needing the conan-qt dep) (Apologies for 3 messages in a row instead of one, on my phone...) |
@jmarrec this is done right? we are using aqtinstall to install official qt for all ci builds right? |
yes |
No description provided.
The text was updated successfully, but these errors were encountered: