| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Unknown if this really helps, depend on if the file was missing
or if it was just failing to find where it is with bad include
search -- but given it is generated good odds it is the former.
Have not actually reproduced myself and it is possible another
target also needs to be run, could potentially fail differently
if that does not resolve it (forcing -j1 is of course out of the
question for this package).
Needs a proper investigation/fix, but given this tend to fail
very late in the build it is not obvious and ccache likely makes
it harder to fail. Does not help that these rules are created
through several Qt cmake wrapper functions (the sync headers
bits come from qtbase cmake files, not from here).
May tentatively try to remove in a somewhat-distant future to see
if it is still an issue, and/or when related-sounding fixes occurred
in qtbase or qtwebengine.
Closes: https://bugs.gentoo.org/915953
Closes: https://bugs.gentoo.org/921680
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
This reverts commit b179a17a6695decb63e3bb7c824a9766b69cf7aa.
Hadn't noticed this had been done for lex as well. Like bison, this
looks for flex directly like bison and does not respect LEX.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
The check was removed before I touched these and didn't know it
existed. Was fair to think it wouldn't be needed anymore with cmake
but it is, e.g. it installs nothing if bison is not found without
hard failure.
File path is hopefully correct for Qt6, did give it two test builds
(one "bad" that's empty, and one full build) just in case. Albeit
haven't retried prefix (it's included in QT6_LIBDIR though).
The qt6-build eclass does force fatal errors for a few "build nothing"
cases, but not qtwebengine's custom ones. Kind of wonder if a similar
end result file check should be done for all of dev-qt/* (aka fail if
does not install anything but cmake files and docs). May revisit if Qt
has more original ways to build nothing not limited to qtwebengine.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
This reverts commit 2e783c9f85e7259aaabc02dbc7175ffb2313f3db.
This may not set YACC, but that's because qtwebengine does not respect
this variable in the first place and looks for bison directly.
This furthermore fails in a horrible way, it installs an empty
qtwebengine when bison is not found (should probably improve this
to hard fail).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
All of these will be using app-alternatives/yacc anyway as they're not unsetting
YACC or LEX, so make the dep reflect reality.
(Included both YACC and LEX out of conservatism.)
Signed-off-by: Sam James <sam@gentoo.org>
|
|
All of these will be using app-alternatives/lex anyway as they're not unsetting
YACC or LEX, so make the dep reflect reality.
(Included both YACC and LEX out of conservatism.)
Signed-off-by: Sam James <sam@gentoo.org>
|
|
6.6-5 -> 6.6-6 changes (only used by 6.6.1):
Added:
* gcc14.patch (imported from gentoo tree, not needed in 6.7)
Updated:
* cstdint.patch (>=qtwebengine-6.6.1 needs an extra for gcc+musl)
6.6-6 -> 6.6-7 changes (due for 6.6.2 if nothing else comes up):
Removed:
* libcxx17.patch (backported from 6.7)
* libxml2-2.12.patch (upstreamed)
6.7-1 -> 6.7-2 changes (tentative, release is still far away):
Updated:
* cstdint.patch (>=qtwebengine-6.6.1 needs an extra for gcc+musl)
Removed:
* libxml2-2.12.patch (upstreamed)
Safe changes, and no need for revbumps.
For libxml2, Qt did the same changes that we did rather than do
like upstream chromium. Meaning we do not need to depend on the
newer libxml2 and it works for the old as well.
Hopefully more gcc+musl issues don't keep showing up given been using
clang+musl for testing musl and would rather not do both on top of
gcc+glibc (idea was to pickup most toolchain issues with only two
builds). Only know about this because a user mentioned it on IRC.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Bit like Qt5's webengine which did not respect it either. Not ideal
but given the complexity tend to be lucky if it builds at all.
As noted in the comment, please report if this works again so can
cleanup (can test with USE=custom-cflags), may get fixed either
by >=qtwebengine-6.7 (chromium-118) or a new gcc version depending
on where the real issue is, but not planning to pursue this further
myself.
Closes: https://bugs.gentoo.org/920555
Closes: https://bugs.gentoo.org/920568
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Bug: https://bugs.gentoo.org/907080
Signed-off-by: Mart Raudsepp <leio@gentoo.org>
|
|
Closes: https://bugs.gentoo.org/920257
Thanks-to: Sam James <sam@gentoo.org>
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
