Arch Linux User Repository

Note that those were actually alternatives. You would rebuild the base packages without "Allow usage of static version with CMake" (and then rebuild this package against it) xor use sed (or rather what I mentioned in my previous comment) to make this package work despite the patch.

By the way, if I manage to build about 1000 packages for my Arch repo (even without Docker!) you can probably manage to build 2 packages :-)

Although it would probably be more interesting to see whether the mentioned "redirection approach" works.

Probably this doesn't even require sed. I suppose one could just add a regular CMake module that redirects to the Static-prefixed version using the same redirection code that is already found in the CMake modules of other packages. It would go like this:

set(ORIGINAL_OVERRIDE_QT_VARIANT_PREFIX ${OVERRIDE_QT_VARIANT_PREFIX})
if(OVERRIDE_QT_VARIANT_PREFIX)
    string(REPLACE "Static" "" OVERRIDE_QT_VARIANT_PREFIX ${OVERRIDE_QT_VARIANT_PREFIX})
endif()
if(NOT OVERRIDE_QT_VARIANT_PREFIX)
    set(OVERRIDE_QT_VARIANT_PREFIX none)
endif()
find_package(StaticQt5AxContainer)
set(OVERRIDE_QT_VARIANT_PREFIX ${ORIGINAL_OVERRIDE_QT_VARIANT_PREFIX})

The same is probably required for the other modules.

If adding files like this works, feel free to submit a ptach for adding those files in the package() function of the PKGBUILD file. (Just ignore the template system. I'd also accept a PR directly modifying the PKGBUILD. I can put it into the template later myself.)

understand ur reasons, although using sed for patching a pkgbuild then rebuild its dependency inside a dockerfile (dockerized toolchain) it is really suboptimal, but seems the only solution atm sigh

sorry but why both static and not-static can't coexists (like in the above mentioned pkgs)?

These packages are based on the Fedora packaging which contained a patch to install shared and static libraries within the same prefix. This was done by the previous maintainer. When I continued maintaining the packages I noticed that it doesn't work with CMake so I fixed that without changing the overall approach. It works for supposedly all modules - just not for this one. So far nobody cared and I personally moved on to caring more about Qt 6 and won't put any bigger effort into Qt 5 anymore. (The combined installation of shard and static libraries has one nice advantage, though: You can link one target in a CMake project against a shared Qt module and another target against a static Qt module - all within the same build.)

Note that Qt 6 works because there I'd decided to ditch the approach and rather install the static build into a nested prefix. (For the sake of simplicity. Of course this means giving up the mentioned advantage.) I suppose that's also how MSYS2 does it for Qt 5 (although I'm not sure whether they eventually made their static Qt 5 build usable via CMake). However, I won't fundamentally change the Qt 5 packaging here anymore - never touch a running system. (And sorry, but the active x module is really not a big concern. And like I said, possibly some sed magic can fix it. That's how I would try to approach it keeping everything else as-is. Of course - as mentioned before - you can also just ditch my patches in the base package for your purposes.)

"Otherwise one might be able to create a "regular" CMake module from the Static-prefixed one via some sed magic."

sorry but why both static and not-static can't coexists (like in the above mentioned pkgs)?

i mean, i think prevent having a pkg with also non-static lib for avoiding somebody using it in the "wrong manner" appears disadvantageous

Looks like the problem is that this module is always only provided as static library. This conflicts with my patches to make the static builds work with CMake at all and to be able to install them under the same prefix as the shared build. The problem is that the CMake module is now only available with the Static-prefix.

I cannot just drop these patches as this would break using the static builds. However, you may drop them (from the base package) if you don't care about the static build. (After dropping the patches from the base package you need to rebuild this one against it.)

Otherwise one might be able to create a "regular" CMake module from the Static-prefixed one via some sed magic.

tried it, seems still missing Qt5AxContainerConfig.cmake (which both AUR mingw-w64-qt6-activeqt and MSYS2 mingw-w64-x86_64-qt5-activeqt & mingw-w64-i686-qt5-activeqt have), that is required by cmake projects that depends on it. thanks

I've pushed the change and the binary package has also been rebuilt.

big thanks man! since the pkg it is not installed on my system, could u notify me here in case? thx

Ok, I'll do that. I'm currently busy updating mariadb-connector-c so I'll do it after that.