Again, goal is more or less to get a baseline where things are
not completely broken. Unless get general failures not going
to worry too much about it.
Intentionally skipping everywhere so this does not come back
for other arches either.
Closes: https://bugs.gentoo.org/914028
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Mostly the same as 11.0.2 bare no longer any unexpected test
failures, minor adjustments due to newer litehtml, and allowing
clang-17.
May still be more that need changes but will give it a closer
look on release unless something comes up first.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Not going to list every changes given this ebuild is from scratch.
There are a few ebuilds for this going around, but they about all
have (IMO) overcustomization, with a lot of USE to juggle for both
users and maintainers (some handled through sed'ing cmake files) --
all while plugins can still be disabled at runtime either way.
So this is now mostly limited to options that introduce an extra
dependency (e.g. clang). "Some" of the longest to build plugins
do have dependencies, so this still allows to cut down build time
a decent amount (not that this is a short build still).
Other small notes:
* Default IUSEs match what Qt Creator enables by default at runtime
(albeit default USE=-tracing could be interesting for faster builds).
* Left gumbo unbundling out for now given ultimate goal is to unbundle
litehtml instead (which itself uses gumbo), but currently it requires
a large patch for 0.8 support (likewise to unbundle on qttools).
wrt bug #905166, delaying cleanup given restoring keywords is
non-trivial and users may need time to adjust for Qt5->Qt6, but
can be dropped anytime anyway if llvm:14 cleanup is happening
(do not consider this a blocker).
Bug: https://bugs.gentoo.org/905166
Closes: https://bugs.gentoo.org/835042
Closes: https://bugs.gentoo.org/905417
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
This matches Qt5 which had been doing the same.
While working on qt-creator bump, noticed that it broke with
qtquick3d-6.5.9999, which turned out because of changes in
private APIs that will land in 6.5.3. In other words, it is
going to need a rebuild when that lands but current SLOT=0/6.5
do not allow this. This could be a one-off issue but let's
stay safer when private APIs are abused.
This also keeps the 9999 in live subslot, so switching
between live and releases will trigger rebuilds too.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
While it still does some compiler/library checks, it does not actually
use any of these and failing where qtbase+qttools dependencies (which
do the same checks) did not would be rather unexpected unless qttools
is broken.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Not packaged so not really an issue, but if it is found odds are it
will end in build failure given this supports litehtml-0.6 and is
broken with (current) litehtml-0.8.
Thought this package it, but would rather wait until that's sorted out
rather than carry rather large patches. Not to mention need to patch
qt-creator for this as well, qlitehtml which wraps around it is not
setup to be unbundled.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
This may bundle litehtml for QtHelp, but assistant does not seem
interested in using html docs over qch.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>