Describe the bug
Hi all! I'm currently (unsuccessfully) trying to build freetype with harfbuzz enabled. The chain of compilation, because of a circular dependency, is said to be as follow:
1) freetype without harfbuzz support
2) harfbuzz with freetype from (1)
3) freetype with harfbuzz from (2)
This should result in a freetype build which is linked to harfbuzz with freetype support enabled. However, I'm stuck at step 3 because meson doesn't recognize the harfbuzz build from (2) - at least not fully. According to the build output after a lot of fiddling around with --cmake-prefix-path and --pkg-config-path, harfbuzz is generally detected but meson is unable to retrieve the version.
I'm trying to build freetype-2.13.3 with harfbuzz 10.1.0, both of which from their official source releases of the given versions (links below).
To Reproduce
1) Grab the releases of freetype and harfbuzz:
https://github.com/harfbuzz/harfbuzz/releases/download/10.1.0/harfbuzz-10.1.0.tar.xz
2) build freetype without harfbuzz support first meson setup build --prefix e:\dev\meson_debug\output\freetype, then ninja install from build folder
3) build harfbuzz with freetype support: meson setup build --prefix e:\dev\meson_debug\output\harfbuzz --cmake-prefix-path e:\dev\meson_debug\output\freetype, then ninja install from build folder
4) try to re-build freetype with harfbuzz support enabled: meson setup build_with_harfbuzz --prefix e:\dev\meson_debug\output\freetype --cmake-prefix-path e:\dev\meson_debug\output\harfbuzz, it should show that harfbuzz isn't recognized
5) update the harfbuzz wrap file of freetype: meson wrap update harfbuzz
6) build again with the wrap file and harfbuzz enabled: meson setup build_with_harfbuzz_wrap --prefix e:\dev\meson_debug\output\freetype -Dharfbuzz=enabled, meson now successfully recognizes harfbuzz
Since I don't know how meson determines the validity of project dependencies, I'm utterly confused by this. Because apparently, if I compile harfbuzz manually, meson doesn't recognize it. However, if I use harfbuzz via the wrap file, meson is able to correctly identify harfbuzz despite being the same version that I used manually.
Expected behavior
Meson correctly identifies harfbuzz if built customly.
system parameters
Is this a cross build or just a plain native build (for the same computer)? plain native build, no cross building
what operating system (e.g. MacOS Catalina, Windows 10, CentOS 8.0, Ubuntu 18.04, etc.)? Windows 10 22H2
what Python version are you using, e.g. 3.8.0? System Python is 3.13, but meson uses its embedded python engine
what meson --version? 1.6.0 (installed via msi from Github release page)
what ninja --version if it's a Ninja build? 1.12.1 (Visual Studio bundled version)
CMake: 3.31 (system), 3.29.5-msvc4 (VS bundled version, not used according to meson output)
everything run from VS2022 x64 Native Tools Command Prompt
At stage four, I assume failure to recognize means meson errors out. It should print the log file containing debug details -- can you post that for inspection?
Describe the bug Hi all! I'm currently (unsuccessfully) trying to build freetype with harfbuzz enabled. The chain of compilation, because of a circular dependency, is said to be as follow: 1) freetype without harfbuzz support 2) harfbuzz with freetype from (1) 3) freetype with harfbuzz from (2)
This should result in a freetype build which is linked to harfbuzz with freetype support enabled. However, I'm stuck at step 3 because meson doesn't recognize the harfbuzz build from (2) - at least not fully. According to the build output after a lot of fiddling around with
--cmake-prefix-path
and--pkg-config-path
, harfbuzz is generally detected but meson is unable to retrieve the version.I'm trying to build freetype-2.13.3 with harfbuzz 10.1.0, both of which from their official source releases of the given versions (links below).
To Reproduce 1) Grab the releases of freetype and harfbuzz:
meson setup build --prefix e:\dev\meson_debug\output\freetype
, thenninja install
from build folder 3) build harfbuzz with freetype support:meson setup build --prefix e:\dev\meson_debug\output\harfbuzz --cmake-prefix-path e:\dev\meson_debug\output\freetype
, thenninja install
from build folder 4) try to re-build freetype with harfbuzz support enabled:meson setup build_with_harfbuzz --prefix e:\dev\meson_debug\output\freetype --cmake-prefix-path e:\dev\meson_debug\output\harfbuzz
, it should show that harfbuzz isn't recognized 5) update the harfbuzz wrap file of freetype:meson wrap update harfbuzz
6) build again with the wrap file and harfbuzz enabled:meson setup build_with_harfbuzz_wrap --prefix e:\dev\meson_debug\output\freetype -Dharfbuzz=enabled
, meson now successfully recognizes harfbuzzSince I don't know how meson determines the validity of project dependencies, I'm utterly confused by this. Because apparently, if I compile harfbuzz manually, meson doesn't recognize it. However, if I use harfbuzz via the wrap file, meson is able to correctly identify harfbuzz despite being the same version that I used manually.
Expected behavior Meson correctly identifies harfbuzz if built customly.
system parameters
meson --version
? 1.6.0 (installed via msi from Github release page)ninja --version
if it's a Ninja build? 1.12.1 (Visual Studio bundled version)