qtbase does a single "big" test for all basic cpu features, and if
CXXFLAGS have any matching -mno-* then they will override Qt's
flags and the test fails. Surprised by this, Qt aborts unless
explicitly disable the feature.
Test can be bypassed, but then it does not perform per-flags
tests and will fail to build as-is.
Like bug #913400, debated a few options:
1. cpu_flags_x86_* to enable each feature, but given this is tied to
compiler flags we'd still need to test them to avoid failures and
not much better off, not to mention bug #913400 may have added its
own -mno-* that go against these.
2. Patching cmake files so it always pass its e.g. -mavx2 after the
user's flags (when needed), and does not rely on -march=haswell
given that does not override. But fwiw these files do get
installed and will alter expected behavior, and handling
-march is more annoying.
3. Patch out the bit that makes the x86intrin test prevent building
unless explicitly disabled, and let it auto-disable x86intrin
entirely if tests fail (subpar for performance if ignored).
4. Do self-tests and disable features that will fail, this has the
advantage that revdeps will not try to use these either.
5. One option to bug #913400 was to force simpler flags, which
would also solve this.
Picked #4 for now, not that particularly like it given it feels
like automagic. Hoping will be more temporary than qsimd_p.h
workarounds. Better than doing nothing either way, is a no-op
for non-affected users.
Bug: https://bugs.gentoo.org/908420
Closes: https://bugs.gentoo.org/913400
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
While it feels more right in configure (along with match_cpu_flags),
sometime need to check/use compiler flags in src_configure and it is
troublesome if not modified until call the eclass' src_configure.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
qsimd_p.h tries determine if x86-64-v3 or v4 sets supported by the
compiler+flags seem complete, and errors out if not. This works out
rather badly on Gentoo, even -march=native can fail with some hard.
With qsimd_p.h being a private header this only affects dev-qt/*
packages, but fwics still need to fix all of dev-qt/* at once given
they are going to be using private bits from qtbase.
Debated a few options for this:
1. Patch headers (like old fix from bug #898644), but just not setting
e.g. __haswell__ is not enough when __AVX2__ still confuses some
code. Then unsetting these without going through the compiler leads
to left over macros and more confusion. Besides... changing system
headers behavior (why is __AVX2__ undef with -mavx2!?) only in
distros tend to end in disaster.
2. Detect issues in qtbase ebuild, then disable x86intrin altogether
if needed (carries over to other modules) + warn users (aka figure
it out yourself). Not really great, users may also end up
mismatching flags between dev-qt/ to fix this and then run into
issues anyway.
3. Backport the next (wip/unmerged) upstream fix[1] but wait, looks
like we are currently still playing whack-a-mole:
# if defined(__AVX2__)
// List of features present with -march=x86-64-v3 and not architecturally
// implied by __AVX2__
# define ARCH_HASWELL_MACROS \
(__AVX2__ && __BMI__ && __BMI2__ && __F16C__ \
&& __FMA__ && __LZCNT__ && __POPCNT__)
# if ARCH_HASWELL_MACROS == 0
# error "Please enable all x86-64-v3 extensions; <snip>
...so -mno-avx2 -mfma (bug #908420) is fine, older (bug #898644)
is too, but if for any reason (VMs, buggy hardware, or the machine
without F16C from bug #910419) anything else is disabled, then the
issue is still there and may in fact trigger more than before.
4. Similarly to #2, detect issues but in the eclass. Then append
-mno-* as needed to flags. Not too bad but passing -mno-*
leads us to bug #913400.
5. Based on users flags, pick highest usable -march=x86-64-v* and
strip everything else (or strip -march too...). Messy and think
users wouldn't be happy about this. It would be what upstream
likely wants us to do though, and causes no further problems.
Ultimately went with #4 for now, bug #913400 needs fixing either way.
- missing from set in #3 += -mno-avx2 (until #3, also -mno-fma)
- missing the AVX512* checked in qsimd_h += -mno-avx512*
(then let compiler disable features that depend on these)
Not great but better than doing nothing, no-op for non-affected users.
[1] https://codereview.qt-project.org/c/qt/qtbase/+/498799
Bug: https://bugs.gentoo.org/898644
Bug: https://bugs.gentoo.org/913400
Closes: https://bugs.gentoo.org/908420
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Essentially a rewrite, so only have a not exhaustive summary
of changes rather than split commits.
Bugs addressed:
* respect *FLAGS wrt bug #652172 (fwics should be no issues left)
* hopefully fixed musl/libcxx (tested with llvm-musl) wrt bug #876520
(not planning to review Qt5's myself, so no changes on that end)
IUSE changes:
* enable alsa by default, finding that you have no audio options
only after building is not great and alsa is cheap
* enable widgets by default, needed by both falkon and qutebrowser
* add custom-cflags, if going to use *FLAGS then should strip-flags
like chromium's ebuild
* add opengl, unfortunately littered in QT_CONFIG(opengl) and need
qtbase[opengl=] to avoid ABI/automagic issues
* add vulkan, has its own feature so should only need qtbase[vulkan?]
* add qml similarly to other packages
Misc:
* support EXTRA_GN like qtwebengine:5 and chromium (Gentoo-specific)
* build dir went from >9GB to ~6.3GB by dropping -g1
* drop estack+extglob, setting extglob is technically not needed for
use in bash [[ ]] tests which is-flagq does
* drop INCLUDEPATH, tried to sed qmake files but this is using cmake
* respect NINJA env var to allow samu (NINJA_PATH was a no-op)
* use get_NINJAOPTS for NINJAFLAGS and ignore environment (NINJAOPTS
is the var to set for this, while NINJAFLAGS is a private
qtwebengine var, ninja does not actually use this directly)
* drop icu's bundling check for simplicity (and consistency with other
system libraries), bug #630834 prompted adding this but does not
seem so fragile anymore (plus iwdevtools would report lib misuse,
albeit not headers)
* switch to bundled re2 to be spared headaches (see github PR#32281)
* optfeature on chrome-binary-plugins for widevine support
* cleanup/reduce QT_FEATURE and old comments
* fix designer automagic
* various dependencies adjustments, wrt re2c that is only needed if
we build ninja
* do not redefine _FORTIFY_SOURCE (use gentoo's defaults), upstream
actually switched to =3 in chromium-118 (albeit only for ChromeOS)
and "hopefully" is fine for this older version (tests pass at least)
Also moved patches to a tarball (like qt5). It is simple small patches
mostly adjusting macros rather than add actual code, but was beginning
to add up.
Considered reducing RAM requirements a little bit (generally *seems*
not so bad), but there is rather bad spikes and I do not think it can
be considered safe unless we assume everyone is not using RAM for
anything else. Plus usage will likely keep growing with versions.
Bug: https://bugs.gentoo.org/652172
Bug: https://bugs.gentoo.org/876520
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
git-r3_src_unpack does not run default/unpack, and then if we have
something else (patchset, assets, or so to unpack) that we need in
live ebuilds as well they'll be skipped.
Currently only needed by qtwebengine, but it would not hurt to have
it ready whenever needed in all esp. given ebuilds do not handle
git-r3 directly (qt6-build does). They would need to conditionally
inherit git-r3 (again) to make pkgcheck happy (and @PROVIDES would
be slightly wrong given conditions).
Tend to feel it would have been nicer if git-r3_src_unpack did this
by itself though.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
clang16+glibc-2.38 -> pass
clang16-musl-1.2.4 -> pass
clang16[hardened]+glibc-2.38 -> pass
gcc13+glibc-2.38 -> pass
gcc13[hardened]+glibc-2.38 -> pass
gcc12[hardened]+musl-1.2.4 -> fail ???
And then, it passes if FEATURES=-pid-sandbox, so it's at least
not broken. Must be hitting some obscure codepath to be stopped
by sandbox (or perhaps that chroot ended up with something different
that activates something)
Have not gotten to the bottom of this, but failing only when using
sandbox is all I need to consider skipping it.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
May potentially be indicating real issues, but revdeps still pass
tests (even qtwebengine, or well, when patched to build with musl)
and, similarly to x86, just going to skip to have a baseline.
Not personally going too deep into musl issues (not using it).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
ebuild is fairly simple, but requirements and options are
a bit convoluted.
Rough overview of requirements (may still not be fully correct):
* (general): network, widgets?, widgets? ( opengl= )
* assistant: sql, sqlite, widgets
* designer: qml, widgets, xml, (opengl=)
* distancefieldgenerator: qml, widgets
* linguist: clang?, qml?, (widgets?)
* pixeltool: widgets
* qdbus: dbus, xml, (widgets?)
* qdoc: clang, qml?
* qtattributionscanner: N/A
* qtdiag: vulkan=, (widgets?, opengl=)
* qtplugininfo: N/A
x kmap2qmap (upstream has this hard disabled)
x qev (likewise)
General libraries can be built with or without opengl/widgets support.
Without widgets some tools will skip subtools, like the GUI linguist6,
or qdbusviewer.
One goal is allowing linguist *without* clang, qtbase[gui,widgets],
or qtdeclarative. This is useful to get lrelease and friends for
revdeps in BDEPEND (notably useful when doing cross-compiling).
There is no feature to skip widgets/declarative support but
disable_find_package does the job just fine.
lupdate can optionally use clang which require a general purpose
USE=clang rather than just qdoc. Also switch to llvm.eclass for this.
Seems fine with both clang:16 and :17 at the moment.
qtdiag is the more annoying one given it uses QT_CONFIG(opengl/vulkan)
meaning will end up broken if disabled on qtbase ([opengl=,vulkan=]).
Fortunately it's disabled by default and won't require typical users
to actually match USE. Albeit does leave a mostly no-op USE=vulkan.
Meant to use opengl? on the others, but cmake_use_find_package may
cause widgets to be disabled because of qtbase's graph.
Also renamed few IUSE to match actual tools name, most of these have
likely few users so should hopefully not be disruptive at this point.
Could argue that qtplugininfo and qtattributionscanner do not need
their own USE (small, no extra deps), but left alone for now
(qtdiag wouldn't either if not for the matching ABI issues thing).
Network could in theory be optional for some tools but CMakeLists.txt
currently hard requires it.
clang dependency could be guarded behind linguist? and qdoc?, but only
feels like extra churn (needs to be checked in pkg_setup too) when it's
rare linguist will be disabled.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Now handled by qt6-build_src_install itself, so can remove
the entire phase.
Symlinks seem identical, just without needing the USE checks.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Primary goal is to reduce the amount of things we need to track,
both what to install and when the symlink needs to be created
based on USE. Without this, a module could introduce a new tool
and may not even notice that it needs a symlink.
Essentially replaces qt6_symlink_binary_to_path which I do not
believe will have further uses (thus marking deprecated). That is,
unless we want to diverge from upstream intended links, but even
then may as well use a normal dosym in ebuilds.
Also re-arrange mycmakeargs a bit because yet again qttranslations
is the odd one out.
Bug: https://bugs.gentoo.org/863395
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Hopefully right, kind of confusing.
Notes:
* qtbase[X=]: checks qtbase for wether to use xlib or not,
we "could" probably force xlib off safely in "this" case
but that still tend to be messy with Qt's ABI
* gst[X=]: similarly checks if enabled through defines, may
possibly break without this if build against gst[X] then
disable it
* qtbase[opengl=,vulkan=]: untested but source is literred in
QT_CONFIG(opengl) and some (vulkan) and would most likely
break if not matching like others (e.g. qtdeclarative) are
known to
* ^ but for gstreamer, we can use gstreamer_gl feature
* qtshadertools is only used to call qsb that I can see, so
move to BDEPEND, albeit does come with the caveat that
(unlike qtdeclarative), it does not look for it separately
to find it during cross-compilation
* qtsvg seems only used by examples, dropping may however have
the downside that very few packages pull qtsvg and it is often
needed by other applications (but it is wrong here)
* pulse[glib] dropped, may have been needed in the past but failing
to see the need for USE=glib right now
X is enabled by default on qtbase, gst-plugins-base, and
here, so it should hopefully not cause mismatch headaches
even on non-desktop profiles (assuming users don't try to
manually enable X/opengl/vulkan per-packages). Pure wayland
systems should be able to avoid X11 entirely with Qt6.
Note that it "looks" for gstreamer even when it is disabled,
so it may give xorg-proto warnings (if missing) if gst was built
with USE=X. Non-issue given in that situation we don't use
gstreamer. If gst[-X], then xorg-proto is not needed at all.
Closes: https://bugs.gentoo.org/910364
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
qttest is now built by default and there is no need to require
USE=gui, and can rely on ebuild's RDEPEND for qtbase itself.
Does come with a caveat that tests may fail if have USE=-gui
until update to >=qtbase-6.5.2-r1, but does not seem worth
having permanent logic to enforce that as it'll be cleared
with 6.5.3 ebuilds depending on =6.5.3*.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Been finding this kind of confusing, and having every ebuilds that
run tests depend on [gui] does not seem right, and also prevent
doing minimalist tests to find issues.
This leaves two option:
1. IUSE="+testlib"
2. enable unconditionally
1 seems sane, but it's not that unusual that revdeps need qttest
for building (even if not running tests, see packages depending
on dev-qt/qttest:5 without 'test?'). qtdeclarative also fails
without it last I know of, meaning most people would need it.
And then qttest has a rather small footprint, rather than hunt
what needs it or not it seems simpler to just always have it
(embedded edge cases can still use MYCMAKEARGS or INSTALL_MASK).
Skipping revbump given was already done once in this commit batch.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Lot of changes here give a full review and re-organizing,
so unfortunately not going to talk about everything.
For IUSE removals:
* freetds (disabled): was a no-op, upstream has the subdir
commented out with a "TODO"
* jpeg (enabled): we already do this for png and IMO should be
extended to jpeg as about anyone with USE=gui will have
libjpeg-turbo either way and it saves headaches for revdeps
* egl (enabled with USE=opengl): same dependency as USE=opengl
and if we try to force egl without opengl (like we were despite
upstream otherwise auto-disables) this results in a build failure
* vnc+tuio (enabled with USE="gui network"): being a USE made
more sense in qt5 given needed to depend on qtnetwork
Notable REQUIRED_USE changes:
* add wayland as an alternative to X and eglfs, eglfs is intended
for embedded devices (without a WM) and is not necessary for
normal wayland to work (technically this requirement is still
not entirely right given other options exists, a postinst to
warn when have nothing set could be an alternative)
* drop || ( evdev libinput ) as a requirement, normally Qt does not
need to handle mouse&keyboard events by itself and this again is for
embedded devices (however keeping libinput by default as I believe
it may be needed for gamepads and other special devices)
Tried to make this bit easier to maintain by making the split between
groups clearer, and also removed some options and left them to
Qt to set based on others (there is a *lot* that could be passed
and it'd be unmaintainable -- can always consider specifics if
users need something special though).
About options, -DFEATURE_reduce_relocations=ON is notably better
removed as it can apparently break things on some arches if forced.
wrt bug #899546, libglvnd is now optional (with [X?] too), and this
removes gtk-update-icon-cache altegether. Latter is only used by one
sub-test (unimportant and auto-skipped if missing), albeit qtgui can
use icon cache if *other* packages used this command which means it
really belong in their IDEPEND (xdg.eclass does this for EAPI=8).
Closes: https://bugs.gentoo.org/899546
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Seems this was formerly droppedin Qt5 due to bug #579208,
but not seeing issues here. Plus it's not great to pull
qtdeclarative by just having USE=wayland on qtbase.
Skipping revbump given already revbumped in this commit batch.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
And drop in live given won't be needed with the version
checks next bump.
Revbump was already done in an earlier commit from this batch.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Not that doing keywording at the moment, but does not hurt to be
prepared (due to a cmake string comparing i*86 with what is likely
x86_64 in the chroot), and then leading to intrinsic inlining failed
build issues.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Automagic happening with QT_CONFIG(vulkan), and libQt6Quick.so breaks
if vulkan is disabled on qtbase.
For shadertools this only use the "qsb" tool (thus why it checks for it
separately in CMakeLists), and such it would need to be BDEPEND. Odds
are a lot of fixing is needed to get cross right with qt6 still though
(i.e. some qtbase in BDEPENDs, maybe need QT_HOST_PATH).
Don't believe sql needs =, sql? should be enough.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Albeit very much unmissable given it inherits system_zlib from
qtbase which itself depends on zlib because of it.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
CMakeLists.txt does check for shadertools but does nothing
with it that I can see (also not listed in dependencies.yaml).
Also depend on [qml] now that it's optional on positioniong.
Skip (+) in live given won't be relevant with =${PV} on bump.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
But enable qml by default given needed by qtlocation... not that
this has any real use right now given nothing depends on qtlocation:6
"yet" while it pulls extra deps for the few packages that depend on
qtpositioning:6, this matches Qt5 anyhow.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
On a side-note CMakeLists.txt noisily looks for MultiMedia rather
than Multimedia which fails, but nothing actually uses this that
I can see either way.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Most of these features are ON by default and add no deps, do not
believe much sense in keeping track of. And opengl+vulkan are
qtbase's features to handle and flipping can have unexpected
consequences.
system_zlib is only for bundled assimp and is default ON either
way (also taken from qtbase).
Technically we could make shadertools optional too but the RHI
renderer is the default+recommended in Qt6 and there is probably
little worth in exposing a USE.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Not a todo, had a closer look at the feature and it's
enabled for "APPLE OR ANDROID OR WASM", so not really
our thing.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* qtbase[icu=]: links directly with it depending on qtbase,
so we need to match and bind := for rebuilds
* qtbase[xml]: bug #911927
* IUSE=qml: can be optional, and will also use shadertools
with qml is found
In theory we could add IUSE="gui xml" too but not convinced
it's worth worrying about on a compat library, imagine roughly
all revdeps will need IUSE="gui" too (unlike qml).
Closes: https://bugs.gentoo.org/911927
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Just an unnecessary disparity between ebuilds to maintain, plus
would typically be inaccurate in live ebuilds (albeit check may
make live version fail on a whim if format changes, but kept
fatal or else issues will be easy to miss on bumps).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
qtwebengine handling of gn does not allow to use CBUILD toolchain,
and only when cross-compiling it will look for system's. Also does
not respect *FLAGS as upstream intentially commented these out
because someone did a bug report with overzealous flags (QTBUG-64759).
And, unfortunately, qtwebengine's is modified and so dev-util/gn
may not work as expected with it (plus will need CMakeLists
modifications to be found).
Bare that, two possible options would be:
1. dev-qt/qtwebengine-gn or so to BDEPEND on and build cleanly
2. fix the mess that is the modified gen.py, and use BUILD_ variables
For now at least skip installing it as it'll just cause conflicts
if we want to do this later and is not really useful unless
want to do something like BDEPEND="cross? ( dev-qt/qtwebengine )".
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Now prexified in qtwebengine:6 itself, albeit the rare users
actually using this on prefix will need to manually rebuild
qtwebengine to get the change if <=qtwebengine-6.5.2.
Given this messed with tests did not want to keep this in
qutebrowser, and it can benefit others.
Technically don't need USE=widevine anymore, but prefer this
over a optfeature at the moment and qutebrowser is fast to
"rebuild" being python-only.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Allows dropping a workaround in qutebrowser. And yes, wrt -w, the line
we are changing literally has "Gentoo" in an upstream comment.
Also move qt6-build_src_prepare up given modifying files before
patches tend to be messy.
No revbump given use case is rather uncommon.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
ebuild needs more real refactoring (will do in a separate revbump),
but at least address pkgcheck's warnings in this one
wrt src_unpack (which triggers indirect git-r3 usage), not quite
sure what the debug check was doing (repeated) there, and (currently)
no patchset to unpack so can just drop the whole thing. For patchsets
this may be better handled in qt6-build given it is the one inheriting
git-r3.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* fix building tests with gcc-13 (backport)
* set both TZ and LC_TIME needed by a few tests (p.m. vs pm)
* skip a few tests with extra needs for simplicity
* skip flaky tests depending on environment/compiler that do not
appear to be real issues (e.g. checks mounted filesystems)
* skip a few tests failing on x86 chroot that do not "seem" to have
consequences, needs more looking into but ultimately want more of
a baseline rather than pursue everything right now
* skip building a test with -Werror=strict-aliasing issues, not
important but saves tinderbox noise (ideally should fix, but well)
* skip tests broken without qtbase already being installed
(these also have issues with out-of-source build, but given
they are broken either way no reason to use IN_SOURCE=1)
* delete bunch of test binaries and files being installed
when tests are enabled (unfortunately not aware of a better
way, upstream may be installing first and using standalone
tests or so)
* set required use, could alternatively skip a few tests based
on USE but this would get further troublesome to maintain
* do not try to use docker-compose if found
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Albeit was almost tempted to just remove the USE as this
will likely cause more problems down the line.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* use -j1 (similarly to when I tried to use python-xdist on
qutebrowser which uses qtwebengine, parallel tests don't
seem to work so well here either)
* skip tests that need network
* skip cert test, not looked too closely but likely missing
something or (maybe) expirations are causing issues
* export various variables to stop it from using the system's
qtwebengine (otherwise fails if not installed)
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Mostly had this figured out but the real issue is when
qtdeclarative is not installed, and this is a far worse
case than qttools or qtbase's few tests to skip.
QML imports are in general pretty messy to run from
tests as-is.
May revisit if the situation improves, albeit given believe
upstream installs before running tests it may not.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Insists on running tools from the system (fails if qttools
is not installed), and even if force the paths (using qt.conf,
or seds), it still has problem finding support files and most
tests fail. Getting all this to work properly would likely
be too messy.
There's also an annoyance with FetchContent, albeit it'd be
easy to handle.
wrt clang, qdoc seems to produce correct output with >=clang-16
but the ordering is slightly altered (believed to be due to
.cpp parsing being bit different) and cause some tests to
fail simple diff comparison -- may not be worth worrying about.
Originally was skipping a lot of tests, but it was utltimately
not meaningful anymore (aka tools were not really tested).
May revisit if the situation improves, albeit given believe
upstream installs before running tests it may not.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
seatv4 is perhaps due to newer libwayland, or the use of offscreen
rendering. But do not believe this would be used with any of the
mostly modern compositors we have packaged if I understand this
right, and so have not looked into this further (tst_seatv7 does pass).
Not fully looked into but the two others seem to be actually trying
to use a compositor (also opengl surfaces). We could run tinywl but
given the majority of other tests do not need that it does not seem
all that worth it (plus would likely be flaky).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Attempts to import a test .dae file but that requires
collada which is hard-disabled in our system copy.
May need revisiting in assimp if someone needs this.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
If someone knows a sane way to stop Qt6 from installing
these (this happens with almost every components, but
eclass deletes tests/ by default at least), please tell me.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Imagine may be more that will need skipping. In my case one
test tried to use NVENC/CUDA but there may be more on systems
that support e.g. vaapi (unlike mine).
Unfortunately have not found a way to tell qtmultimedia to
use a dummy audio input/output wrt the other tests.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Ionen Wolkens