|
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>
|
|
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>
|
