| Age | Commit message (Collapse) | Author |
|---|
|
Three of these are gone but still add blockers for old updates.
Closes: https://bugs.gentoo.org/966328
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
wrt llvm21, only tested 6.10 but "think" 6.9 should've gotten
the backports for it (6.9.2 was broken), will test when 6.9.3
is about to release to be sure.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Upstream disabled this by default with the reason that system
version is almost always incompatible, may as well drop the
comment as well because of this.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
wrt bug #9146766, this loses some .desktop for the minor
tools, but given upstream added its own mechanism to install
these would rather stick to the ones that they want to be
installed. Ideally please ask upstream if you want more to be
installed.
wrt clang, upstream dropped support for using clang with lupdate
(USE=linguist) and so it is now only used by qdoc, may as well
merge USE=clang into it.
Bug: https://bugs.gentoo.org/914766
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Happened to notice this while testing 6.9.0 with llvm-musl, and
this been broken since 6.8.3 (with USE=clang) that had the same
change picked to.
CMake Error at cmake/FindWrapLibClang.cmake:72 (find_package):
find_package called with invalid argument "20.1.1+libcxx"
At first I thought this was caused by our sed, but that specific
line is unmodified and is using ${LLVM_VERSION} which has the
+libcxx bit appended (or at least, it does with llvm:20). This
is Qt's attempt at getting a "matching" version for Clang.
Given we are trying to remove version specifications to let the
eclass pick them instead (will always match), may as well just
remove it as well.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
On one hand, the majority of users do not need the GUI assistant or
linguist, but on the other the cmake build system does not easily
split the GUI and their support libraries (Help/UiTools) very well
which needs us to build both.
As a non-optimal solution, *could* consider something like USE=gui
that would `rm` them but it feels kind of silly when already built
them and it would not really save any runtime-only dependencies.
Just keep a note about this situation for now.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Qt added new logic for clang selection where it iterates through
a list of supported version and always picks the most recent one
from that list ignoring the eclass.
May be a better way, but for now just remove the version check.
Does not seem to have been backported to 6.8, so leaving that
one alone.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Given pkg_setup is not exported with LLVM_OPTIONAL, may as
well use llvm_chost_setup directly in src_configure rather
than define pkg_setup.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Intentionally skipping revbump, see linked bug.
Closes: https://bugs.gentoo.org/947045
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
Previously failed to build with 19, but seems fine now.
.cmake.conf also indicates a new minimum of 17.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
QtHelp may possibly be split out of qttools in the future
which would be more convenient for us as well.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Bug: https://bugs.gentoo.org/930266
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Not that many revdeps (yet) beside 3 kde/plasma packages, but is
rather trivial to build and only needs qtbase[dbus,xml] which are
already default. Feel it's not worth being profile-specific.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Currently ommited in the llvm-r1 example, but that's being changed
and >=llvm-18.1.0_rc3 will use $(ver_cut 1-2) as subslot.
No need for a revbump (slot 18 is still masked either way).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Tested with 18.1.0_rc2 at same time, seems to be fine so may
as well do this now.
Skip .cmake.conf comment in 6.6.9999 given the minimum was
introduced in 6.7+. Unsure how often Qt intend to bump this,
odds are we may not need to pay attention to it if we clean
old versions up faster.
Not changing 6.6.1 given 6.6.2 is close and it can be updated
at same time to spare rebuilds.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Normally harmless (tries to find it, either does or not and will not
use it either way), but if the cmake files are in broken state then
it can abort entirely.
Unsure if it fully resolves bug #916098 (for portage, ideally these
should still be updated "together" as much as possible), but at least
should not trigger on qttools anymore for those not enabling clang
(tested by intentionally breaking llvm's cmake files).
Closes: https://bugs.gentoo.org/916098
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Build system now checks for minimum clang version, and we still
have the unusable clang:14 in-tree.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Forgot, albeit typically not an issue unless someone has an extra
llvm slot without clang.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Not very worth a revbump considering 6.5.3 is around the corner,
but does not hurt to have it for stable early as this just should
not be missing.
Descriptions and categories may need extra work, but should do
for now.
Also sync with live while revbumping.
Closes: https://bugs.gentoo.org/914766
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Provides QtHelp, and lacking that by default is likely to be
an annoyance given the amount of packages that previously
depended on dev-qt/qthelp:5. No urgency to trigger a rebuild,
so queue'ing it for next release.
Technically requires no extras assuming default IUSE on qtbase,
albeit may eventually pull litehtml if unbundled.
Unfortunately does mean that the optfeature will nag about
qt-docs when it is primarily intended for developers.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: WANG Xuerui <xen0n@gentoo.org>
|
|
Did suspect that qdoc would become its own option eventually.
It now also requires qml and clangcpp (on top of clang), not
that we really need to pass clangcpp feature given it does
no test and just mirrors the clang feature.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Based on qtbase configuration, so yet another annoying [match=].
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
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>
|
|
Pulling by default does feel like a stretch, especially
given this also provides QtHelp in this unsplit qttools
and may just be pulled a dep.
But no harm in an optfeature.
Bug: https://bugs.gentoo.org/602296
Bug: https://bugs.gentoo.org/881435
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Same as opengl and vulkan, qtdiag has the whole slew of
QT_CONFIG that would break if qtbase disables support.
Albeit unfortunate with unsplit qttools given USE is a
no-op (like vulkan) unless qtdiag is enabled.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Less jarring a little bit shorter. Made sense in Qt5 given it used
a ver_cut QT5_PV and could be used to ignore additional components,
but with PV it does nothing useful. Plus we still want _rc and _betas
to match (_p<date> are where issues start though, if ever needed we
could reintroduce QT6_PV, but for now...).
Should have done this in the previous style commit.
Still keeping :6, do prefer these being everywhere for clarity with
Qt slots (and qa-vdb!) even if essentially a no-op here. Plus, even
if this does not happen with Qt, two slots having the same version
can happen with revisions (e.g. current webkit-gtk).
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>
|
|
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>
|
|
Misc minor adjustments / sorting, but more commonly:
* use same RDEPEND + DEPEND ordering everywhere, bit of both
order is used all across and sometime inverted in Qt5's so
let's match skel.ebuild to avoid confusion
* use explicit :6 slots, not necessary with =PV but this is more
about normalizing usage when multiple slots exist (plus *cough*
qa-vdb won't complaint anymore)
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
As-is, no changes in this commit which is mostly the same
as the current in-tree ebuilds.
Maintaining these in two different repos feels like just a hassle
(to me), and would rather have everything in one place so I can
change live and release ebuilds simultaneously as needed, plus not
have to sync metadata or eclass changes either (plus chiitoo has
::gentoo commit access now).
May move packages if I happen to work on them, albeit I have no
intention to really touch Qt5 or LXQt (anyone working on these
are free to the same if they want, or keep current workflow).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
