Package Details: mingw-w64-harfbuzz-icu 10.1.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 (ICU integration, mingw-w64)
Upstream URL: https://harfbuzz.github.io/
Keywords: harfbuzz harfbuzz-icu mingw mingw-w64
Licenses: MIT
Submitter: Schala
Maintainer: pingplug
Last Packager: pingplug
Votes: 14
Popularity: 0.000000
First Submitted: 2013-12-02 10:12 (UTC)
Last Updated: 2024-11-15 12:51 (UTC)

Latest Comments

1 2 3 4 5 Next › Last »

Martchus commented on 2024-05-10 10:56 (UTC)

Could you add this change? https://github.com/Martchus/PKGBUILDs/commit/047fd653344265c5419bff79f4742469a2078184

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?

1 2 3 4 5 Next › Last »