Bump QT Creator 8

[Peter-Levine]

• dev-qt/qt-creator: add 8.0.1
  Switched from the qmake to cmake buildsystem. Added support for the Coco code coverage tool. The 'git' USE flag now also builds the gitlab plugin. The 'wayland' flag was added to enforce built-with-use dependency. 'imageviewer' flag is added for conditional dependence on dev-qt/qtsvg.

• dev-qt/qt-creator: drop 6.0.0 and 9999
  6.0.0 is shadowed by 8.0.1 and 9999 requires QT6.

Closes: #26675
Signed-off-by: Peter Levine plevine457@gmail.com

[gentoo-bot]

Pull Request assignment

Submitter: @Peter-Levine
Areas affected: ebuilds
Packages affected: dev-qt/qt-creator

dev-qt/qt-creator: @Pesa, @gentoo/qt

Linked bugs

No bugs to link found. If your pull request references any of the Gentoo bug reports, please add appropriate GLEP 66 tags to the commit message and request reassignment.

If you do not receive any reply to this pull request, please open or link a bug to attract the attention of maintainers.

---

In order to force reassignment and/or bug reference scan, please append [please reassign] to the pull request title.

Docs: Code of Conduct ● Copyright policy (expl.) ● Devmanual ● GitHub PRs ● Proxy-maint guide

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2022-07-31 00:16 UTC
Newest commit scanned: 9fd2253
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/ad0d8f74e9/output.html

[Pesa]

I only took a very cursory look at the ebuild, but I'm not sure I like adding tons of USE flags, even for the smallest plugins that have no additional deps (keep in mind that plugins can also be enabled/disabled at runtime). I went back and forth on this several times in the past, but honestly I don't see a good reason to not build the bookmarks or the todo plugin...

[thesamesam]

Not a user of qt creator at all but @Pesa please ping me if/when it's ok to merge if you're unable & if you need me to.

[Peter-Levine]

and there's no telling when QT6 will land in the gentoo repo

Still masked but it apparently just hit the main repo.

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2022-08-06 06:56 UTC
Newest commit scanned: cdc2891
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/a76e077905/output.html

[Peter-Levine]

@Pesa What I just git-pushed only has IUSE="clang doc imageviewer qml serialterminal systemd wayland webengine debug designer qt6 test". With regard to plugin related USE flags kept, designer depends on dev-qt/qttools[designer] and serialterminal depends on dev-qt/qtserialport. They may be too trivial to keep, as per whatever you recommend. QT6 support is safely added behind the qt6 USE flag since it is use.masked in profiles/base. Building with USE=-webengine now builds the bundled qlitehtml. It pulls in dev-libs/gumbo as a dep. though, instead of relying on the bundled one since it's already in the main tree. It builds the bundled xxd utility because it's a single c file, AFAICT it is only used at build-time and not installed, and the only in-tree package to install it is app-editors/vim-core which is an unreasonable dep for such a small hex dump utility. All other plugins and tools are default installed with exception to the cplusplus tools, as they are with every other distro. The cplusplus tools (cplusplus-mkvisitor, cplusplus-update-frontend, cplusplus-ast2png, and cplusplus-frontend) are never default installed and appear to be IDE development specific.

If you want to revert, remove, or add anything, let me know.

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2022-08-06 07:41 UTC
Newest commit scanned: a803229
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/9ffa7a7edd/output.html

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2022-08-06 07:51 UTC
Newest commit scanned: 4a6d112
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/07901044d1/output.html

[Pesa]

I'm not sure why you can't just follow what the existing (6.0) ebuild is doing, where applicable. It seems as if you're writing a new ebuild from scratch rather than doing a version bump. Granted, this is not a trivial bump due to the qmake->cmake switch, but the two build systems have coexisted in qt-creator for years and are almost identical in many aspects.

[Pesa]

@Pesa What I just git-pushed only has IUSE="clang doc imageviewer qml serialterminal systemd wayland webengine debug designer qt6 test".

Now I think you removed too many. I was probably not sufficiently clear before, the decision behind whether something deserves a flag or not depends on 1) the size of the plugin (some users have complained about compilation times), 2) additional dependencies, 3) whether the plugin is popular or niche/specialized. For example, a large plugin that is likely to be used by very few users should be behind a flag, disabled by default, even if it doesn't have any additional build-time deps (one such example is baremetal IIRC). Some plugins may look small but they use some QtCreator internal libraries that quickly increase the amount of compiled code. Other flags exist for historical reasons, for instance qbs, it used to have a build-time dep but that's no longer needed. These flags can probably be dropped if you want, assuming the plugin has a reasonable size.

With regard to plugin related USE flags kept, designer depends on dev-qt/qttools[designer] and serialterminal depends on dev-qt/qtserialport.

These are fine.

QT6 support is safely added behind the qt6 USE flag since it is use.masked in profiles/base.

Regarding Qt6, if it makes things easier, I'd be ok with keeping qtcreator-8.0 Qt5-only, and then quickly adding a Qt6-only 9.0_beta once it becomes available (a couple of months from now). I haven't been involved much in Qt6 packaging but it seems unlikely that it will be unmasked in the near future anyway.

Building with USE=-webengine now builds the bundled qlitehtml. It pulls in dev-libs/gumbo as a dep. though, instead of relying on the bundled one since it's already in the main tree. It builds the bundled xxd utility because it's a single c file, AFAICT it is only used at build-time and not installed, and the only in-tree package to install it is app-editors/vim-core which is an unreasonable dep for such a small hex dump utility.

Sounds good.

All other plugins and tools are default installed with exception to the cplusplus tools, as they are with every other distro

Again, my preference would be to roughly follow what the existing 6.0 ebuild does, unless there's a reason to deviate (such as removing USE flags for small-ish non-niche plugins).

The cplusplus tools (cplusplus-mkvisitor, cplusplus-update-frontend, cplusplus-ast2png, and cplusplus-frontend) are never default installed and appear to be IDE development specific.

Yeah those tools should not be compiled at all. Nothing new here.

[hansfn]

I just tested the current 8.0.0 ebuild (for Qt Creator 8.0.1) and discovered two problems:

1. I had to add include(FindPkgConfig) in the root CMakeLists.txt since pkg_check_modules was used in src/libs/qlitehtml/src/CMakeLists.txt (Upstream bug?) I'm using cmake 3.24.0.
2. I had to install gumbo manually as it was a dependency of qlitehtml that wasn't listed in the ebuild.

But now I'm running Qt Creator 8.0.1. Happily so far.

[Pesa]

I just tested the current 8.0.0 ebuild (for Qt Creator 8.0.1) and discovered two problems:

Thanks for testing!

2. I had to install gumbo manually as it was a dependency of qlitehtml that wasn't listed in the ebuild.

I'm puzzled by this one, the ebuild does have a dependency on gumbo... are you building with or without USE=webengine?

[hansfn]

Sorry, how could I miss gumbo - it's there:
!webengine? ( dev-libs/gumbo )
Yes, I'm building without webengine.

I just assumed it wasn't there because I didn't get an error, but I guess it was because I used ebuild to build and install/merge the package instead of emerge. My bad.

[Peter-Levine]

I'm not sure why you can't just follow what the existing (6.0) ebuild is doing, where applicable. It seems as if you're writing a new ebuild from scratch rather than doing a version bump. Granted, this is not a trivial bump due to the qmake->cmake switch, but the two build systems have coexisted in qt-creator for years and are almost identical in many aspects.

This is the first time I ever examined the CMake files. The cmake and qmake build files in qtcreator are not mirror images of one another. There are a number of differences. As a trivial example, zstd compression support in perfparser existed, but wasn't addressed, in .pro/.pri. And with cmake, I can run ebuild ... configure and then examine ${BUILD_DIR}/CMakeCache.txt for configuration flags, or at least the ones that aren't shadowed by the inclusion or absence of others, before I even look at a CMakeCache.txt. I'm not nearly as fluent with qmake so correct me if I'm wrong, but AFAIK there is no qmake equivalent. qmake -query list only standard Gentoo QT_INSTALL_FOO flags. Which means I'd have to look at every .pro and .pri and hope that I've dotted every "i" and crossed every "t". If you go in to the subdirectory of src, you'll see that the qmake files are gone. To make sure that I've accounted for all changes between 6.0.0 and 7.0.0 or 8.0.0, I did start from scratch. The original intention was afterwards, to go back and compare 6.0.0 to 8.0.0 and adjust the 6.0.0. build with whatever appeared new. That was the part I neglected and it sort of took on a life of its own. . I'll amend that.

Having examined the plugins' deps and size, IMHO, bineditor, bookmarks, classview, emacskeys, fakevim, macros, marketplace, and todo should be considered candidates for use flag removal and unconditional building. I would be for dropping "studiowelcome" entirely. It appears to be a broken vestige from the split with Qt 3D Studio. Even in upstream's own extractable build, clicking on an Example leads to a "Failed opening project" error.

Edit: So I can see now why the plugin selection of 6.0.0 is superior. I suppose it would make sense to keep qmldesigner flag since that is the biggest plugin, too.

Edit2: qmldesigner and studiowelcome aren't built with QT5 now, anyway.

[Peter-Levine]

@Pesa The debugger plugin looks like it's implicitly enabled in 6.0.0. According to its CMakeFiles.txt, it has a dependency on the qmake plugin when test is enabled. Should I add a debugger USE flag and add something like test? ( debugger? ( qmake ) ) to REQUIRED_USE or take away the qmake flag and build it unconditionally, along with debugger?

Edit: So much appears to depend on qmake and qbs during test, including a few default enabled plugins, that it just makes sense to add test? ( qbs qmake ) to REQUIRED_USE.

Edit2: I'm aware that debugger tests are seded out in 6.0.0, but with cmake the bad ones are omitted by passing -DWITH_DEBUGGER_DUMPERS=NO.

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2022-08-15 02:21 UTC
Newest commit scanned: f7a31e5
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/67b214c817/output.html

[Peter-Levine]

@Pesa OK. It's now pretty much based on the IUSE profile of 6.0.0. qt6 was removed but, if anyone wants, I could reopen the PR in the qt overlay for 9999 and/or 8.* with qt6 support. Tests are working and gtest is unbundled.

test? ( mcu? ( dev-cpp/gtest:= ) ) dependency was added, on top of the one already in DEPEND, since libMcuSupport.so gets installed with symbols that need to be resolved from gtest/gmock at runtime. If you want me to omit mcu testing instead, let me know.

There looks to be optional support for dev-qt/qtquick3d:5 in qml2puppet. There's no such ebuild for it but I can add it if you want.

coco? ( lsp ) and test? ( qbs qmake ) were added to REQUIRED_USE based on PLUGIN_TEST_DEPENDS tags in plugins' CMakeLists.txt.

qch files are now correctly installed to /usr/share/doc/${PF}. qtcreator correctly adds them to the Help viewer on my end.

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2022-08-15 03:06 UTC
Newest commit scanned: 6e25c2c
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/59922d27eb/output.html

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2022-08-16 06:02 UTC
Newest commit scanned: 96cd8cf
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/5d8c5cc692/output.html

[Peter-Levine]

@Pesa There's also plugin-haskell and plugin-fossil-scm which I could eventually add support for, either in build or separately, if they're useful enough and you and/or qt-project accept maintainer status.

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2022-08-20 03:56 UTC
Newest commit scanned: f7362e2
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/65b4f41b21/output.html

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2022-08-20 23:42 UTC
Newest commit scanned: 7f92cf6
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/40829fda2e/output.html

[Peter-Levine]

Taking a look at qt-creator/qt-creator@780f89b and the 8.0.0 changelog, it would appear that, although not explicitly needed at build time, clangd functionality depends on >=clang-14* at runtime. I could make the dep a pure RDEPEND on top of what's already in CDEPEND, but IMHO it greatly simplifies things just to edit the existing clang dependency expression. And given that they removed the libclang based code model in 8.0.0, it seems to me that clangd is likely not something that should be optional when the clang USE flag is set.

[thesamesam]

Is this good to go now? The LLVM 13 dep is becoming problematic.

[thesamesam]

ping. I'm going to merge it in a few days if no serious objections which can't be handled later, in light of the LLVM 13 dep and how far we're out of date.

[Pesa]

sorry, I've been mostly disconnected for the past month or so. Give me a couple of days to take another look, there were a few major changes since my last review.

[thesamesam]

No worries at all, just let me know. Thanks!

[Pesa]

Edit: So much appears to depend on qmake and qbs during test, including a few default enabled plugins, that it just makes sense to add test? ( qbs qmake ) to REQUIRED_USE.

Yeah that's fine.

Edit2: I'm aware that debugger tests are seded out in 6.0.0, but with cmake the bad ones are omitted by passing -DWITH_DEBUGGER_DUMPERS=NO.

Yes, the dumpers tests were disabled in 6.0.0 and all previous versions, they never worked for me.

There looks to be optional support for dev-qt/qtquick3d:5 in qml2puppet. There's no such ebuild for it but I can add it if you want.

Given that the next version of qtcreator will drop Qt5 altogether, I'd say don't bother.

coco? ( lsp ) and test? ( qbs qmake ) were added to REQUIRED_USE based on PLUGIN_TEST_DEPENDS tags in plugins' CMakeLists.txt.

OK

qch files are now correctly installed to /usr/share/doc/${PF}. qtcreator correctly adds them to the Help viewer on my end.

Are you somehow telling qtcreator where to find them? If not, it may appear to be working because this is a -r0 ebuild so the revision component is omitted from the install path, but it will stop working for -r1 and higher.

[Pesa]

Taking a look at qt-creator/qt-creator@780f89b and the 8.0.0 changelog, it would appear that, although not explicitly needed at build time, clangd functionality depends on >=clang-14* at runtime. I could make the dep a pure RDEPEND on top of what's already in CDEPEND, but IMHO it greatly simplifies things just to edit the existing clang dependency expression. And given that they removed the libclang based code model in 8.0.0, it seems to me that clangd is likely not something that should be optional when the clang USE flag is set.

I'm not following. Your ebuild already depends on clang-14, what other dependency changes are you suggesting?

[Peter-Levine]

I'm not following. Your ebuild already depends on clang-14, what other dependency changes are you suggesting?

Sorry for the miscommunication. I was announcing the change I had just previously applied and my reasoning.

[Peter-Levine]

Are you somehow telling qtcreator where to find them? If not, it may appear to be working because this is a -r0 ebuild so the revision component is omitted from the install path, but it will stop working for -r1 and higher.

Yes, right here. I tested the ebuild by temporarily changing it to qt-creator-8.0.1-r2.ebuild and re-emerging, and can confirm it still shows the documentation in the help viewer.

[hansfn]

Any chance of getting this reviewed / merged?

[Peter-Levine]

@Pesa QT Creator 9.0.0 Beta 1 is out now. I understand if time is very limited but I feel there has been sufficient testing and feedback, both here and in the QT overlay PR, to warrant merging this.

[imwints]

Version 8.0.2 is out now. I managed to compile it already with the same ebuild.

[genbtc]

Any progress getting this merged properly ? Bump