Skip to content
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

qt6: Add initial qt6 ports #12676

Merged
merged 8 commits into from Nov 9, 2021
Merged

qt6: Add initial qt6 ports #12676

merged 8 commits into from Nov 9, 2021

Conversation

jhoyt4
Copy link
Contributor

@jhoyt4 jhoyt4 commented Oct 25, 2021

Description

Adds some initial QT6 capabilities / sub ports.

Additional subports will be added in future PR's - this PR is mainly to get an initial set of qt6 based sub ports working.

Happy to have another set of eyes on this for tips and/or help

Closes Ticket 62982

Type(s)
  • bugfix
  • enhancement
  • security fix
Tested on

macOS 11.6 20G165 x86_64
Xcode 13.0 13A233

AND

macOS 11.6 20G165 arm64
Xcode 13.0 13A233

Verification

Have you

  • followed our Commit Message Guidelines?
  • squashed and minimized your commits?
  • checked that there aren't other open pull requests for the same change?
  • referenced existing tickets on Trac with full URL?
  • checked your Portfile with port lint?
  • tried existing tests with sudo port test?
  • tried a full install with sudo port -vst install?
  • tested basic functionality of all binary files?

"tested basic functionality of all binary files?" - qt6 is rather expansive - saying that I could check all executables would be a stretch....

@reneeotten
Copy link
Contributor

thanks @jhoyt4 for this! I started myself two weeks ago or so using the qt5 PG and Portfile as starting point. I attempted to first clean-up the Portfile and PG (and comments in there) and make sure that all the latest modules are present (you appear to have only a small subset?). A difference compared to Qt5 is that upstream switched to CMake as a build systems, so that's likely something we want to do as well - I didn't manage to get all that far yet though. I can take a look at what you did and how that compares to my initial attempt...

@jhoyt4
Copy link
Contributor Author

jhoyt4 commented Oct 25, 2021

I attempted to first clean-up the Portfile and PG (and comments in there) and make sure that all the latest modules are present

I took a similar approach - this versions should be close to qt5 with pieces removed (especially the docs code) to get an initial Portfile / qt6 group working.

(you appear to have only a small subset?).

Again correct and intentional. Not everything works out of the box and some of the modules have new / updated dependencies. I worked on a handful to show proof of concept figuring more can be added later.

A difference compared to Qt5 is that upstream switched to CMake as a build systems, so that's likely something we want to do as well - I didn't manage to get all that far yet though.

Yep - that was not a fun piece to figure out. Thankfully the cmake 1.1 group is close to what was needed to get the modules compiling.

Thanks for the help! I'd be very happy to look at/factor in whatever work you've done (or vice versa have you modify your work and I close this PR).

@jhoyt4
Copy link
Contributor Author

jhoyt4 commented Oct 26, 2021

It looks like QT just dropped QT6.2.1, so I'll be updating this to that version.

I'm also now struggling to compile qt6-qtbase - I uninstalled qt5 from my machine to test some issues and now it won't line.

This PR certainly could use the WIP label...

@mascguy
Copy link
Member

mascguy commented Oct 26, 2021

It looks like QT just dropped QT6.2.1, so I'll be updating this to that version.

I'm also now struggling to compile qt6-qtbase - I uninstalled qt5 from my machine to test some issues and now it won't line.

This PR certainly could use the WIP label...

I'm happy to add the label. But you can also change the status of this to Draft, while you're making changes. That will prevent anyone from prematurely merging.

Once you're done, change the status to Ready for Review.

@mascguy mascguy added wip Work in progress DO_NOT_MERGE_YET labels Oct 26, 2021
@jhoyt4 jhoyt4 marked this pull request as draft October 26, 2021 20:00
@jhoyt4
Copy link
Contributor Author

jhoyt4 commented Oct 27, 2021

Those last two force pushes have fixed the build process (needed to force qt-base as a depend for all sub ports), updated the ports to 6.2.1, and removed an unnecessary opengl path patch (I should have removed it from the original submission as it didn't solve any real problem).

Last night's push seems to have gotten everything through lint and build checks - so I think I'm close.

Still happy to get more eyes on this if anyone has the time to test it further.

@mascguy
Copy link
Member

mascguy commented Oct 27, 2021

Those last two force pushes have fixed the build process (needed to force qt-base as a depend for all sub ports), updated the ports to 6.2.1, and removed an unnecessary opengl path patch (I should have removed it from the original submission as it didn't solve any real problem).

Last night's push seems to have gotten everything through lint and build checks - so I think I'm close.

Still happy to get more eyes on this if anyone has the time to test it further.

Awesome! While my QT-related knowledge is a bit light, I'll try to take a closer look over the coming days.

I'd encourage more QT-savvy folks to jump in as well, though.

@abey79
Copy link
Contributor

abey79 commented Oct 27, 2021

@jhoyt4 FWIW, I got an error trying to install it on my brand new Monterey/M1 Max laptop (main.log). That being said, this is my first time testing a new port, so I may well have messed up at some point.

Here is what I did for reference:

  • checked out your branch
  • ran portindex in it
  • prepended file:///path/to/your/macports-ports to /opt/local/etc/macports/sources.conf
  • sudo port install qt6

Background: I'm on a mission to have PySide2 5.15.2 (or at least PySide6) run on Apple silicon. I've managed with the official Qt6 distribution built from source, but having that part sorted out by MacPorts would be great.

@jhoyt4
Copy link
Contributor Author

jhoyt4 commented Oct 27, 2021

@jhoyt4 FWIW, I got an error trying to install it on my brand new Monterey/M1 Max laptop (main.log). That being said, this is my first time testing a new port, so I may well have messed up at some point.

Here is what I did for reference:

  • checked out your branch
  • ran portindex in it
  • prepended file:///path/to/your/macports-ports to /opt/local/etc/macports/sources.conf
  • sudo port install qt6

@abey79 That should have got it running. The error you're seeing is similar to the one I saw a couple days ago that I resolved by removing "use Xcode" from the portfile. I wonder if Monterey has something new in the SDK that's causing the issue.

The other thought is do you have qt5 installed? I uninstalled it on my x86 machine and things are compiling (...that being said, it's also installed on my M1 mini and things compile there as well...)

@jhoyt4 jhoyt4 marked this pull request as ready for review October 27, 2021 23:49
@jhoyt4
Copy link
Contributor Author

jhoyt4 commented Oct 27, 2021

@mascguy - it looks like I got everything through the lint and build process. Basic QT6 functionality seems to be working on my machines as far as I've tried tested.

@kencu - any chance you have some spare cycles to look over the Portfile. You were a huge help last year when we got qt5 [mostly] working

@abey79
Copy link
Contributor

abey79 commented Oct 28, 2021

@jhoyt4 Not that I know what I'm doing, but I tried to add set use_xcode to the portfile and got the same error.

As for Qt5, I don't have installed (with MacPort, that is) because this fails. Here is the related error log, should it have any relevance. The errors are different though (c: No such file or directory), and look similar to errors I got while trying to build PySide2 from source with an incorrect toolchain.

Edit: if this helps, I'm happy to make myself available for further Monterey testing in the coming days, including with a more "real time" interaction if needed/practical.

@jhoyt4
Copy link
Contributor Author

jhoyt4 commented Oct 28, 2021

@abey79 This probably isn't the right place to help you troubleshoot qt5 - take a look at this trac ticket https://trac.macports.org/ticket/63154.

Also, it appears a PR was just issued for SDK12. I'll have to see if the new patch file can be grafted into this PR to help with qt6 issues.

Also - just to verify, you have commandline tools installed?

@jhoyt4
Copy link
Contributor Author

jhoyt4 commented Oct 28, 2021

@abey79 - I just pushed the patch from PR 12711. See if that helps you in the build process.

Also - happy to have the help, thank you!

@abey79
Copy link
Contributor

abey79 commented Oct 28, 2021

This probably isn't the right place to help you troubleshoot qt5 - take a look at this trac ticket https://trac.macports.org/ticket/63154.

@jhoyt4 yeah totally. I just posted there in case it could have any relevance to this particular issue. Thanks for the pointer though.

Also - just to verify, you have command-line tools installed?

You mean Xcode command line tools? Yes, I do have them installed.

I just pushed the patch from PR 12711. See if that helps you in the build process.

It does. I could install qt6 successfully after updating.

@jhoyt4
Copy link
Contributor Author

jhoyt4 commented Oct 30, 2021

That last commit should fix a lot of issues for applications that use cmake to build. The main problem was that shifting to building moduls with cmake broke the Portfile's mechanism to symlink the lib/cmake files.

@jhoyt4 jhoyt4 marked this pull request as draft October 31, 2021 00:50
@jhoyt4
Copy link
Contributor Author

jhoyt4 commented Oct 31, 2021

Converting back to draft as I work through a TON of new dependency issues as I try to bring additional qt submodule features online

The majority of these are induced by qtdeclarative trying to get qtquick working threading QtQuick through the rest of the ports

@jhoyt4
Copy link
Contributor Author

jhoyt4 commented Nov 5, 2021

I've been hammering away trying to resolve an issue where optional features in a TON of the modules fail to configure if QtQuick (installed by qtdeclarative) is available. This all started after I added qtshadertools which qtdeclarative automagically picks up as a dependency.

My current thoughts are that I am going to remove qtshadertools from the portfile / dependencies to get things building / an initial cut at the Portfile ready for submission. This way we at least get some qt6 functionality (i.e. a default build) working and available.

@jhoyt4
Copy link
Contributor Author

jhoyt4 commented Nov 5, 2021

Builds? issue Notes
qt6 yes
qt6-mysql-plugin yes
qt6-psql-plugin yes
qt6-qt3d partial Fails with QtQuick
qt6-qt5compat partial Fails with QtQuick
qt6-qtbase yes
qt6-qtcharts no Hold back due to qtmultimedia
qt6-qtconnectivity yes
qt6-qtdeclarative partial QtQuick causes issues, thanks qtshadertools
qt6-qtimageformats yes
qt6-qtlocation partial Fails with QtQuick
qt6-qtmultimedia no Hold back due to qtshadertools
qt6-qtnetworkauth yes
qt6-qtremoteobjects yes
qt6-qtscxml no Hold Back due to QtQuick Fails with QtQuick
qt6-qtsensors partial Fails with QtQuick
qt6-qtserialbus yes
qt6-qtserialport yes
qt6-qtshadertools yes Hold Back due to QtQuick
qt6-qtsvg yes
qt6-qttools yes
qt6-qttranslations yes
qt6-qtwebchannel partial Fails with QtQuick
qt6-qtwebsockets partial Fails with QtQuick
qt6-sqlite-plugin yes

@jhoyt4
Copy link
Contributor Author

jhoyt4 commented Nov 5, 2021

Assuming I just fixed the conflict with qt-base and the SQL-plugins (i.e. it gets through the lint and build checks), I'll be marking this "Ready for review"

@jhoyt4 jhoyt4 changed the title QT6: Add initial QT6 ports qt6: Add initial qt6 ports Nov 5, 2021
@jhoyt4 jhoyt4 marked this pull request as ready for review November 6, 2021 10:09
@jhoyt4
Copy link
Contributor Author

jhoyt4 commented Nov 8, 2021

That rebaseline should pull in openssl 3, we'll see how this goes...

    Currently, there is an issue where the existance QtQuick induces an
    error in most qt modules as they attempt to link against QtQuick
    QtQuick is installed optionally by QtDeclarative if qtshadertools
    is located.
…ensors, webchannel, and websockets

qt6: configure flag and dependency clean up, add qtremoteobjects, qtsensors, webchannel, and websockets
… based build to better align with Qt's build guide

     Additionally fix the cmake file patching mechanism to be recursive
@jhoyt4
Copy link
Contributor Author

jhoyt4 commented Nov 8, 2021

That rebaseline should pull in openssl 3, we'll see how this goes...

@mascguy - followed your tip on the other PR to rebase [hopefully] the right way

@jhoyt4
Copy link
Contributor Author

jhoyt4 commented Nov 9, 2021

Looks like it built with openssl3. I also just finished building qt6-qtbase on macOS 12.0.1 21A559 arm64 / Xcode 13.1 13A1030d without any issues.

@mascguy mascguy self-assigned this Nov 9, 2021
@mascguy mascguy removed wip Work in progress DO_NOT_MERGE_YET labels Nov 9, 2021
@mascguy
Copy link
Member

mascguy commented Nov 9, 2021

Looks like it built with openssl3. I also just finished building qt6-qtbase on macOS 12.0.1 21A559 arm64 / Xcode 13.1 13A1030d without any issues.

Haven't scrutinized every line, but looks great overall!

Are you ready for us to merge this?

@jhoyt4
Copy link
Contributor Author

jhoyt4 commented Nov 9, 2021

I think I'm ready for the merge - would still have liked another few sets of qt-saavy eyes on it.

Either, way, I'll keep an eye on trac to help troubleshoot any tickets that pop up.

@jhoyt4
Copy link
Contributor Author

jhoyt4 commented Nov 9, 2021

@reneeotten @kencu - Any chance you two have some additional time to look over the Portfile before it gets merged?

@chrstphrchvz
Copy link
Contributor

Could we please not add plugins for end-of-life versions of MariaDB (5.5, 10.1, maybe even soon-to-be EOL 10.2)? It would be easier to propose removing old versions of MySQL, MariaDB, etc. if there weren’t so many ports/variants still depending on them.

Copy link
Contributor

@chrstphrchvz chrstphrchvz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe qt6-qtbase as proposed is affected by https://trac.macports.org/ticket/62104: qtbase opportunistically enables Vulkan support if Vulkan headers are detected on someone’s system, which may lead to build failure. If others approve of the fix I proposed in #12837 (explicitly disable Vulkan support), I suggest incorporating it into qt6-qtbase as well. Although, it may be desirable to eventually explicitly enable Vulkan support.

Do not opportunistically enable Vulkan support
(maybe it can be explicitly enabled later if desired)
Fixes: https://trac.macports.org/ticket/62104
@jhoyt4
Copy link
Contributor Author

jhoyt4 commented Nov 9, 2021

@chrstphrchvz - Done. I have removed the EOL database plugins, but if its still reported to be developed (i.e. mariadb-10.2, mysql5.7) I have left it in the portfile.

@mascguy - should I squash all commits into one? I left them as multiple to help any reviewers understand what was changing while this was a WIP.

@mascguy
Copy link
Member

mascguy commented Nov 9, 2021

@mascguy - should I squash all commits into one? I left them as multiple to help any reviewers understand what was changing while this was a WIP.

I'm fine with leaving them as multiple commits, to maintain the history. Does anyone have an objection to that?

@mascguy
Copy link
Member

mascguy commented Nov 9, 2021

The CI builds passed, so let's merge. Awesome work @jhoyt4!

@mascguy mascguy merged commit 68dfdf7 into macports:master Nov 9, 2021
@reneeotten
Copy link
Contributor

reneeotten commented Nov 11, 2021

thanks @jhoyt4 ! I am sorry but haven't had the time to take a thorough look at this - will give it a spin myself locally and see if I can get some more things to build and/or if changes are needed.

(The commits should have been squashed, or perhaps one for the PG and one for the qt6 port, though before merging as per our PR checklist; if you ask for opinions you'll need to give some time for people to actually look at it and not just merge the same day)

@chrstphrchvz
Copy link
Contributor

should I squash all commits into one? I left them as multiple to help any reviewers understand what was changing while this was a WIP.

As a note, an open GitHub pull requests shows all of the times when its branch was force-pushed, and all of the previous commits are still available. (I would still squash at least whenever there are changes which should be made simultaneously.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
6 participants