LLVM 8 is next on the removal list, please look into supporting 9+.
Ping. I can do FEATURES=test run on the PR and merge it if that helps.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=24dd58fe4592775fe430ee98d17ecb7825a02ade commit 24dd58fe4592775fe430ee98d17ecb7825a02ade Author: Peter Levine <plevine457@gmail.com> AuthorDate: 2020-05-08 07:11:14 +0000 Commit: Jason A. Donenfeld <zx2c4@gentoo.org> CommitDate: 2020-06-25 07:11:04 +0000 dev-qt/qt-creator: Support clang-10 Builds and runs without issue using patch from https://codereview.qt-project.org/c/qt-creator/qt-creator/+/299377 Closes: https://bugs.gentoo.org/720240 Closes: https://bugs.gentoo.org/711788 Package-Manager: Portage-2.3.99, Repoman-2.3.22 Signed-off-by: Peter Levine <plevine457@gmail.com> Signed-off-by: Jason A. Donenfeld <zx2c4@gentoo.org> .../files/qt-creator-4.12.0-dylib-fix.patch | 84 ++++++++++++++++++++++ dev-qt/qt-creator/qt-creator-9999.ebuild | 13 +++- 2 files changed, 95 insertions(+), 2 deletions(-)
Not fixed until cleanup, so re-using for stabilisation. Depends on Qt 5.15 stabilisation right now due to dev-qt/qtquicktimeline being only available as 5.15.0.
*** Bug 707308 has been marked as a duplicate of this bug. ***
Unable to check for sanity: > dependent bug #726846 is missing keywords
Unfortunately LLVM-10 stabilisation has already started, which breaks current stable qt-creator. However, 4.12.3 requires Qt 5.15.0 due to dev-qt/qtquicktimeline only being available in that version. We could fast-track stabilisation here by stable-masking IUSE=qmldesigner.
(In reply to Andreas Sturmlechner from comment #6) > However, 4.12.3 requires Qt 5.15.0 due to dev-qt/qtquicktimeline only being > available in that version. I have no idea where this information is coming from, but qtquicktimeline tags and tarballs are available from Qt upstream starting with version 5.14.0, including current version 5.14.2: https://code.qt.io/cgit/qt/qtquicktimeline.git/refs/tags https://download.qt.io/official_releases/qt/5.14/5.14.0/submodules/ https://download.qt.io/official_releases/qt/5.14/5.14.0/submodules/qtquicktimeline-everywhere-src-5.14.0.tar.xz https://download.qt.io/official_releases/qt/5.14/5.14.2/submodules/qtquicktimeline-everywhere-src-5.14.2.tar.xz It builds fine for me. But I can't comment anything on it's stability or usability.
The information comes from gentoo.git obviously.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=293314869a4a70ff5537f0b0e30c788ff4b9957d commit 293314869a4a70ff5537f0b0e30c788ff4b9957d Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2020-06-30 22:05:22 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2020-06-30 22:06:30 +0000 profiles: Add dev-qt/qt-creator[qmldesigner] to p.use.stable.mask Bug: https://bugs.gentoo.org/720240 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> profiles/base/package.use.stable.mask | 4 ++++ 1 file changed, 4 insertions(+)
@pesa, did you spot any issues with 4.12.3 as it is right now?
All sanity-check issues have been resolved
(In reply to Andreas Sturmlechner from comment #10) > @pesa, did you spot any issues with 4.12.3 as it is right now? What's the plan regarding dev-libs/libclangformat-ide? This new package was committed with me as the only maintainer, but I never agreed to that. The package has a non-trivial build system and I don't have the time nor the motivation to maintain it, especially considering that I don't even use the clang-format plugin in qt-creator.
(In reply to Andreas Sturmlechner from comment #6) > Unfortunately LLVM-10 stabilisation has already started, which breaks > current stable qt-creator. > > However, 4.12.3 requires Qt 5.15.0 due to dev-qt/qtquicktimeline only being > available in that version. > > We could fast-track stabilisation here by stable-masking IUSE=qmldesigner. Drop stable keywords from all qt-creator versions?
Also possible. The flag was already masked for now anyway. (In reply to Davide Pesavento from comment #12) > What's the plan regarding dev-libs/libclangformat-ide? This new package was > committed with me as the only maintainer, but I never agreed to that. Understandable, and it would be entirely justified to simply reassign that package to zx2c4. Would there have been a different way to solve that situation that you were pondering before the PR got merged by zx2c4?
(In reply to Andreas Sturmlechner from comment #14) > Would there have been a different way to solve that situation Like, e.g., tuck clangformat away behind a different USE flag, p.use.stable.mask and assign resulting bugs to zx2c4?
(In reply to Davide Pesavento from comment #12) > What's the plan regarding dev-libs/libclangformat-ide? This new package was > committed with me as the only maintainer, but I never agreed to that. The > package has a non-trivial build system and I don't have the time nor the > motivation to maintain it, especially considering that I don't even use the > clang-format plugin in qt-creator. Sorry. I put you down in metadata.xml because you maintain qt-creator. I'd proxy-maintain dev-libs/libclangformat-ide but I actually use kdevelop as an IDE. I only needed qt-creator to follow along with a book and didn't want to depend on sys-devel/clang:8. One thing led to another. (In reply to Andreas Sturmlechner from comment #14) > Would there have been a different way to solve that > situation that you were pondering before the PR got merged by zx2c4? Just to touch on this a bit, the following are three ways I can think of to resolve the patched libclangformat issue without bundling, two of which I mentioned in https://github.com/gentoo/gentoo/pull/15711#discussion_r426110780. 1. Create libclangformat-ide ebuilds for all versions of clang that qt-creator can use. This is the solution I ultimately submitted. Advantages: A. Ensures that the correct version of libclangFormat.a is linked to libClangFormat.so, managed in its own ebuild that mimics a simplified sys-devel/clang. Disadvantages: A. Have to maintain extra ebuilds for each supported version of sys-devel/clang. B. Though libclangformat-ide isn't technically needed after linking with qt-creator, it has to be treated as an rdep (as there is no feasible way to ensure the version that satisfies the clang runtime dep is the exact same version that satisfies the libclangformat-ide buildtime dep). 2. Have qt-creator depend on only one version of sys-devel/clang and have the qt-creator ebuild download and unpack its source, build libclangFormat.a with qt-creator, link it during compile, and install qt-creator. Advantages: A. No need to maintain any libclangformat-ide. No need to install libclangFormat.a or a patched header. Disadvantages: A. Only one supported version of clang. B. A more complicated qt-creator ebuild that would, itself, have to duplicate a lot of logic from sys-devel/clang. C. A SRC_URI that would have to include the clang tarball with hackish calls to eclass functions like 'S="${WORKDIR}/clang" llvm.org_src_unpack'. 3. Make a local, custom ebuild of sys-devel/llvm that builds llvm with no USE flags as a static library linked to a sys-libs/zlib that, itself, is built with USE=static-libs. Then build a local, custom libclangformat-ide ebuild that links to the static llvm. Compress the libclangFormat.a and it's patched header into a tarball and have Gentoo mirror it. Have qt-creator conditionally unpack it and link to it at build time when USE="clangformat". Advantages: A. You need only one version of the tarball and it would be independent of whichever version of clang that satisfies qt-creator's dependency. This is because, assuming I'm understanding the linking behavior correctly, all transitive dependent symbols would be resolved and all dependent object files would be included in qt-creator's libClangFormat.so plugin. The rest of qt-creator would link against the system's normal clang shared library. B. That same tarball could continue to be used for any later versions of qt-creator that would otherwise be satisfied by the tarball's clang version. C. No patched library or header would have to be installed. Disadvantages: A. Having to build a custom library from 2 custom ebuilds. B. Having qt-creator rely on a pre-built library to link to in a source-based linux distribution. These are all atrocious solutions to an atrocious problem.
(In reply to Peter Levine from comment #16) > Sorry. I put you down in metadata.xml because you maintain qt-creator. It's okay, ultimately the person merging the PR should give it more than a cursory glance.
FWICS only a middle ~arch version technically blocks LLVM 8, so I'll start with removing that.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=842efe4025a43783b75b6750c715d4cc8f4b8293 commit 842efe4025a43783b75b6750c715d4cc8f4b8293 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2020-07-29 11:42:13 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2020-07-30 22:09:51 +0000 dev-qt/qt-creator: Remove redundant ver (LLVM 8) Bug: https://bugs.gentoo.org/720240 Signed-off-by: Michał Górny <mgorny@gentoo.org> dev-qt/qt-creator/Manifest | 1 - dev-qt/qt-creator/qt-creator-4.10.1.ebuild | 201 ----------------------------- 2 files changed, 202 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ab525e44f7de257497bb96ea9459327f62b2d841 commit ab525e44f7de257497bb96ea9459327f62b2d841 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2020-08-03 05:45:30 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2020-08-03 05:45:30 +0000 profiles: Add >=dev-qt/qt-creator-4.12[clang] to p.use.stable.mask Bug: https://bugs.gentoo.org/720240 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> profiles/base/package.use.stable.mask | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
Both IUSE="clang qmldesigner" are now stable masked. Any objections to start stabilisation?
I recommend dev-util/qbs-1.16.0 since there is some incompatibility between dev-qt/qt-creator-4.12.3 and <dev-util/qbs-1.16 causing qbs projects, using Depends clauses to resolve dependencies with pkg-config, to fail. someproject.qbs import qbs QtApplication { Depends { name: "openssl" } // qbs versions prior to 1.16 will fail to resolve this with pkg-config consoleApplication: true files: [ "main.cpp", ] }
Thanks for your comment, 1.16.0 was in tree for long enough already.
Can we CC arches now? Or am I missing a blocker? (I get it's not a simple issue here.)
I won't add arches without pesa's ACK. Otherwise I'd say we drop qt-creator to ~arch by the end of August.
(In reply to Andreas Sturmlechner from comment #25) > I won't add arches without pesa's ACK. Otherwise I'd say we drop qt-creator > to ~arch by the end of August. @pesa, any views here?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=918fa8ded423c49295b8d5237e04f0314e008d96 commit 918fa8ded423c49295b8d5237e04f0314e008d96 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2020-09-03 14:22:25 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2020-09-08 18:07:40 +0000 dev-qt/qt-creator: Drop 4.8.2, destabilising package This also leaves dev-util/qbs without any stable revdep so could be cleaned up. Bug: https://bugs.gentoo.org/720240 Package-Manager: Portage-3.0.5, Repoman-3.0.1 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> dev-qt/qt-creator/Manifest | 1 - dev-qt/qt-creator/qt-creator-4.8.2.ebuild | 192 ------------------------------ 2 files changed, 193 deletions(-)
So now the package was destabilised. Note this does not yet address the point made in comment #12.
