Arch Linux User Repository

Then I propose the following: Make a mingw-w64-harfbuzz-bootstrap package that depend on mingw-w64-cairo-bootstrap. That way the build will look like mingw-w64-cairo-bootstrap -> mingw-w64-harfbuzz-bootstrap -> mingw-w64-cairo -> mingw-w64-harfbuzz.

Moreover, I think bootstrap packages shouldn't conflict or provide what they are bootstrapping. They should be installed in a separate location to avoid conflict and packages can depend on them as make dependencies, if it is sufficient for building. Packages can then add a dependency on the full package in their package(), as these dependencies are required only at runtime. This way I think we could break dependency cycles.

Example: Building mingw-w64-freetype2 should result in something like: mingw-w64-freetype2-bootstrap -> mingw-w64-cairo-bootstrap -> mingw-w64-harfbuzz-bootstrap -> mingw-w64-cairo -> mingw-w64-harfbuzz -> mingw-w64-freetype2 and there would be no build dependency cycle.

The cycle is weird, but ultimately correct. You first have to install the bootstrap, then harfbuzz, then Cairo, then harfbuzz again.

How can it depend on mingw-w64-cairo as a make dependency? You get a unbreakable dependency loop: harfbuzz -> cairo -> fontconfig -> freetype2 -> harfbuzz. Since it is a make dependency, it can't use bootstrap packages. Unless cairo-bootstrap is sufficient, then it should depend on that.

IMHO. Recomendation for fix small problem. cp "${srcdir}/harfbuzz/src/hb-ft.h" "${pkgdir}/usr/${_arch}/include/harfbuzz/"

hb-ft.h - not included in package!!! Compile error mingw-w64-gtk3

I am, and your workaround did the trick. Thanks, and thanks for [ownstuff] too.

Are you by any chance trying to use the static library? That doesn't work with the CMake find module. Not sure what has changed so that it is now attempted to be used. I had to workaround it as well when updating Qt, see e.g. https://aur.archlinux.org/cgit/aur.git/commit/?h=mingw-w64-qt6-svg-static&id=b3ad8ec6e24e01c3569b7aade438498c3fb65fbc. Note that the find module is also broken when just building a static library for GNU/Linux (like https://github.com/Martchus/PKGBUILDs/blob/master/harfbuzz/static-compat/PKGBUILD). Supposedly upstream doesn't support this use case at all.

Getting this in a CMake project since the last update.

CMake Error in CMakeLists.txt:
  IMPORTED_IMPLIB not set for imported target "harfbuzz::harfbuzz"
  configuration "Release".

I read the CMake config and can not see anything that sticks out to me that would cause this. Anyone have any ideas?

@Denzy7 Wanted by upstream. Use mingw-w64-freetype2-bootstrap to break the circle; build mingw-w64-freetype2-bootstrap, mingw-w64-harfbuzz and mingw-w64-freetype2 in that order. You can get rid of the bootstrapping package afterwards. On the next update you can of course simply use the existing packages to satisfy the dependency.

Or you just use my binary repo: https://wiki.archlinux.org/title/Unofficial_user_repositories#ownstuff

Circular dependency with mingw-w64-freetype