Package Details: mingw-w64-harfbuzz 8.3.0-1

Git Clone URL: https://aur.archlinux.org/mingw-w64-harfbuzz.git (read-only, click to copy)
Package Base: mingw-w64-harfbuzz
Description: OpenType text shaping engine (mingw-w64)
Upstream URL: https://www.freedesktop.org/wiki/Software/HarfBuzz
Keywords: harfbuzz harfbuzz-icu mingw mingw-w64
Licenses: MIT
Submitter: Schala
Maintainer: pingplug
Last Packager: pingplug
Votes: 15
Popularity: 0.000000
First Submitted: 2013-12-02 10:12 (UTC)
Last Updated: 2023-11-16 09:23 (UTC)

Latest Comments

1 2 3 4 5 Next › Last »

patlefort commented on 2023-12-04 01:50 (UTC)

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.

janisozaur commented on 2023-12-03 23:39 (UTC)

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

patlefort commented on 2023-12-03 23:30 (UTC)

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.

badcast commented on 2023-07-25 15:20 (UTC)

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

badcast commented on 2023-07-25 15:03 (UTC)

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

Vaporeon commented on 2023-07-23 18:09 (UTC)

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

Martchus commented on 2023-07-23 07:48 (UTC) (edited on 2023-07-23 07:49 (UTC) by Martchus)

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.

Vaporeon commented on 2023-07-23 03:54 (UTC)

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?

Martchus commented on 2022-04-08 15:41 (UTC)

@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

Denzy7 commented on 2022-04-08 15:02 (UTC)

Circular dependency with mingw-w64-freetype