qgis: update to 4.0.3; New package: libblend2d-0.21.2

[nezos]

Testing the changes

• I tested the changes in this PR: YES

New package (libblend2d-devel)

• This new package conforms to the package requirements: YES

Local build testing

• I built this PR locally for my native architecture: x86_64-glibc

Note: Fixes also incompatibility problems installing plugins due to qt6 build of the latest 3.x version.
Note2: blend2d was introduced as it is required for building qgis

@ar-jan if you want to review it also, thanks.

[nezos]

Dropped support for 32bit. There is no package for qt6-webengine in 32bit plus since 2020 it was announced that moving to qt6, 32bit will no longer be supported:
https://blog.qgis.org/2020/10/15/phasing-out-32-bit-support-in-qgis/

[ar-jan]

Thanks for doing the update! I hadn't gotten around to adding libblend2d yet. You can also update it to 4.0.3 now.

[nezos]

fixed a mistake in shlibs

[classabbyamp]

i don't like these changes outside of the builddir, they will leak to other builds

[nezos]

As I understand, there must be some hard-coded paths which I could not find a way to change. I could not find another solution.

[ahesford]

You might be able to make a wrapper in $XBPS_WRAPPERDIR to invoke the right version. Grep around other templates to see examples, especially those that mess with Qt.

No matter what, it is definitely not acceptable to corrupt the build environment in this fashion.

[nezos]

The paths are obtained using QT macros inside the build scripts. I could not intercept them. Please notice that both hostmakedepends and makedepends provide the same executables due to dependencies (packages needed in makedepends indirectly install the same package as in hostmakedepends but for different architecture). An alternative way I found was to alter the build.ninja and point to the correct path in a pre-build stage. I built both aarc64 and x86_64 locally and there was no problem.

Just to note that variables like QT_HOST_PATH (which is included in the template) do not affect the lrelease executable location, which is otherwise executed in the target arch. I also checked templates for XBPS_WRAPPERDIR and QT but, if I understood correctly, this is a different situation as this is a "side-tool".

I hope this is an acceptable solution.

[ahesford]

This is the kind of hack that makes me think you don't fully understand the issue. For this to be acceptable in principle, you'll have to describe the root cause and explain why it shouldn't be fixed the right way. Also, the details are just wrong:

1. These kinds of changes belong in post_configure, not pre_build.
2. The test is wrong, because this is an artifact of cross building, not aarch64 builds.
3. The test shouldn't treat glibc and musl separately; that just leads to this unnecessary duplication.
4. There is no need to change directories to run this command; use the proper relative path for the target file given the existing working directory.
5. Use vsed to detect when the patch is no longer applied.

Ideally, to address points (2) and (3), you should construct the sed string without hard-coding the cross root, so a single correction applies regardless of target architecture. Then you have a single if [ -n "${CROSS_BUILD}" ]; ...; fi to do a single replace.

[nezos]

Root Cause of the Problem - 1
The executable needed to run in host is lrelease:

$ xlocate lrelease
qt6-tools-6.11.1_1                 /usr/lib/qt6/bin/lrelease

In the template file:

makehostdepends: qt6-tools
makedepends:  qscintilla-qt6-devel

Checking dependencies:

$ xbps-query -Rx qscintilla-qt6-devel
qt6-tools-devel
$ xbps-query -Rx qt6-tools-devel
qt6-tools

This leads to the duplicate installation of lrelease:

$ find ./ -name "lrelease"
./usr/lib/qt6/bin/lrelease
./usr/aarch64-linux-gnu/usr/lib/qt6/bin/lrelease

Root Cause of the Problem - 2
In QGIS source code, in i18n/CMakeLists.txt there are these macros that are associated with lrelease (lrelease is used for the translations):

` find_package(${QT_VERSION_BASE} COMPONENTS LinguistTools REQUIRED)
set(QT_LRELEASE_EXECUTABLE ${QT_VERSION_BASE}::lrelease)`

If I understand correctly, as I am not familiar with qt, the find_package will search for Qt6Config.cmake, which comes from:

$ xlocate Qt6Config.cmake
qt6-base

but when searching the builddir of qgis in masterdir

find ./ -name "Qt6Config.cmake"
./usr/lib/cmake/Qt6/Qt6Config.cmake
./usr/aarch64-linux-gnu/usr/lib/cmake/Qt6/Qt6Config.cmake

because:
makedepends = qt6-base-private-devel
and

$ xbps-query -Rx qt6-base-private-devel
qt6-base-devel
$ xbps-query -Rx qt6-base-devel
qt6-base

but probably (?) saved from the QT_HOST_PATH variable.
Similarly, if we search for LinguistTools component, the cmake file is include in qt6-tools package:

$ xbps-query -Rf qt6-tools | grep LinguistTools
/usr/lib/cmake/Qt6LinguistTools/Qt6LinguistToolsConfig.cmake

for which we have the same situation:

$ find ./ -name "Qt6LinguistToolsConfig.cmake"
./usr/lib/cmake/Qt6LinguistTools/Qt6LinguistToolsConfig.cmake
./usr/aarch64-linux-gnu/usr/lib/cmake/Qt6LinguistTools/Qt6LinguistToolsConfig.cmake

Thoughts
From what I deduce with all these macros and dependencies and as I have no experience with Qt I cannot think of a different solution. There is no variable to set, I have not seen a Find*.cmake file since it uses packages, cmake config files mention that they will be automatically replaced on every run and, ontop of these, the interdependencies of the packages cannot be overcome the way (void)packages are organized (qt seems to be too complicated).

If I understood something wrong, please correct me. Also if someone can think something better, please feel free to change or suggest.

@ahesford Regarding the suggestions 1-5 you mentioned, I understand 1-4 but I have no clue on what to do for 5.

[ahesford]

Neither one of these is a root cause. It is clear that there are host and target duplicates of these files, but the real issue to understand is why the build system prefers the wrong one and how best to address that at its origin.

There are at least two workarounds that will be cleaner than patching ninja build rules after the fact:

1. Patch the CMakeLists.txt file(s) in the qgis source tree to hard-code the right version; or
2. Find a way to remove the conflicting package, if possible.

[ahesford]

As for vsed, we offer a function to wrap sed which compares the input file to the modified output to confirm that changes were actually applied. Grep around srcpkgs to see other invocations of vsed.