Allow meson builds depending on other ports

[NNemec]

Meson's dependency mechanism searches for either a pkg-config file or a Find???.cmake file. Neither of these mechanisms works to find packages within a vcpkg installation. An option for manually resolving external dependencies does not seem to exist either in meson. The only two ports within vcpkg currently using meson do not require any dependencies so the problem obviously never came up and there is example one could look at to learn how it supposed to be done.

This is a significant hurdle for updating GTK+ and the other GNOME libraries. In principle, meson offers everything needed to build them out of the box, but it is not clear at all how this should be integrated in vcpkg.

[MVoz]

https://github.com/Voskrese/vcpkg/tree/master/ports/pkgconf

vcpkg\installed\x64-windows\bin\pkg-config.exe --variable pc_path pkg-config

vcpkg\installed\x64-windows\debug\bin\pkg-config.exe --variable pc_path pkg-config

*.PC to prefix=.. or full path, default
debug include = includedir=${prefix}/../include /../

or use fake-pkg-config

example
https://github.com/fujii/vcpkg/blob/gstreamer/ports/gstreamer/pkg-config.bat

[NNemec]

The problem is not the missing pkg-config executable (I believe meson does not even need that) but the missing .pc files of the various ports.

[MVoz]

Well, if pkg-config executable meson is not needed ... then I am powerless

wait can someone else answer

And what do not you like the option with fake-pkg-config ?

[MathiasMagnus]

I may very well have to climb down this rabbit hole, having to compile GEGL on Windows (the back-end of GIMP) which depends on numerous pkg-config and mesonized libraries, BABL for instance primarily builds with meson. Many parts of the dependency graph are already inside Vcpkg, a few need to be added.

[MathiasMagnus]

Matching topic I opened on the Meson forums: https://groups.google.com/forum/#!topic/mesonbuild/OEB0UIlLl0A

[MathiasMagnus]

FWIW, here's the code for the CMakeDependency class in Meson. I'm not adept at reading Python, but will have to make friends with it to make ends meet.

My guess is that it generates some dummy CMakeLists.txt file with a find_package() entry and invokes CMake on it and parse the cache or use cmake-server. If a CMAKE_TOOLCHAIN_FILE entry could be fed to it from outside (meson cli invocation?), we would be set.

[MVoz]

is there a promotion on the issue?

[cenit]

@MathiasMagnus thanks for investigating the issue. Thanks to https://github.com/mesonbuild/meson/blob/7b9c348102792030859ed0001a51416506a0a092/mesonbuild/dependencies/base.py#L1082 it's not difficult to fix it
I have done it in my PR about aravis #8595, but I will decouple it asap because I fear that it's going to take much more time to finish that port... in the meantime you can start exploiting meson in vcpkg sooner! :)

[MathiasMagnus]

@cenit. Thanks for putting in the effort. Are you sure however that the CMAKE_PREFIX_PATH is enough? There is so much more going on inside the vcpkg.cmake (for starters, overriding the find_package command as it is...

I'll try giving your PR.

[cenit]

It is working as a minimum to find libraries by vcpkg, which otherwise were completely missed. Without the find_package override it misses the vcpkg-cmake-wrapper for sure, will look into it next to see if it is possible to attach to it. But at least we have a working starting point. Before I agree with you it was totally non working (even plainly wrong outside windows...)
Now it is becoming at least on par with nmake/jom and make. Not sure if it’s possible, it is a different build Engine at the end of the day and so it might require different things (I was also trying with pkg-config in Windows, might abandon the idea very soon...)

[MVoz]

I already wrote, for meson it is in vcpkg variable CMAKE_PREFIX_PATH will not work
the default folder location has been changed

meson does not look for cmake configuration files in folder share

p/s/ the more vcpkg changes the default settings \ environment, the more integration problems occur

[cenit]

Check my pr. Meson there obeys with vcpkg CMAKE_PREFIX_PATH and can find configuration files in our share folder :)

[MVoz]

I don't see much difference between

set(ENV{CMAKE_PREFIX_PATH} "${CURRENT_INSTALLED_DIR}")

and

-Dcmake_prefix_path=${CURRENT_INSTALLED_DIR})

#6977 (comment)
"C:/Program Files/cmake/bin\cmake.EXE" -G "Visual Studio 10 2010" --trace-expand -DNAME=libelf -DARCHS= -DCMAKE_PREFIX_PATH=E:/tools/vcpkg/installed/x64-windows .

-Dcmake_prefix_path=${CURRENT_INSTALLED_DIR}) = -DCMAKE_PREFIX_PATH=E:/tools/vcpkg/installed/x64-windows .

[cenit]

The second one does not work, the first one works :)

[cenit]

Meson does not obey to -DCMAKE_PREFIX_PATH passed from command line, but listen only to that variable if set in the environment

[cenit]

I can show you that I was having a warning on command line that the definition was unrecognized. While at the same time now I can use ports installed in share folder. Missed that pr and the fact that was considered working by someone. I am very confused now

[MVoz]

#7044 (comment)

meson look in folder

installed/x64-windows/Cmake
installed/x64-windows/lib/Cmake

[MVoz]

although it is possible that something has changed in the MESON code, since then
and your edits really work, in General it is necessary to look

at myself I made a simplink and part of configurations began to be picked up
it's better than nothing

x64-windows\lib\cmake <<-->> x64-windows\share\cmake
x64-windows\cmake <<-->> x64-windows\share

p/s/
symbolic link windows xp-10
http://schinagl.priv.at/nt/ln/ln.html

[cenit]

I think it was not working before. Looking at the meson code, the variable passed from command line was wrong, it had to be an environment variable. With this in mind, you don’t even need a symbolic link like you did, since share/<port name> is a default folder checked for config files by cmake.
Again, not perfect, but much better than before. I think now we can start having meson ports that depend on other ports :)

[MVoz]

could you try to collect the last GLIB through MESON ?

[cenit]

sorry first of all i have to make aravis work and for that i only have my spare time, which is not a lot

[c72578]

although it is possible that something has changed in the MESON code, since then

Relevant upstream info and fixes can be found here:

Issue: Meson CMake dependency lookup ignores CMAKE_PREFIX_PATH after recent changes
mesonbuild/meson#5666
PR: cmake: Read CMAKE_PREFIX_PATH environment variable
mesonbuild/meson#5673
Commit: meson: Use CMAKE_PREFIX_PATH environment variable
mesonbuild/meson@e2499fa
This commit is in meson 0.51.2 and newer.

[c72578]

In the meantime, meson has been updated to 0.52.0 in vcpkg (see #8639, af55822), which includes the fix concerning the CMAKE_PREFIX_PATH environment variable.

[Neumann-A]

Just want to add the following meson issues:
#6883 (-> only Release libraries are linked via CMake)
and
#6663 (-> libname of static builds is incompatible with CMake's find_library on windows)

so meson on windows is just a mess and the discussions in PRs also show not much regard to the windows platform.

[cenit]

Sad situation for meson on windows. It's a pity, that another build system is gaining traction (unfortunately, but that's life) and it will leave Windows behind... I hope that someone from the vcpkg team can start discussions with upstream meson and maybe work together. It might unlock a lot of libraries!

[Neumann-A]

another build system is gaining traction

Doesn't feel like they are gaining traction except for gnome usage.
From the discussions in their PRs it seems they did not learn a lot from CMake and are making the same errors again and again. They should just have stay with autotools. Since I worked with both I can tell getting meson to work correctly is more complex than autotools due to a massiv lack of good documentation. Considering meson has been in development since roughly 8 years (or 4 years depending where you start to count) it feels still very buggy and incomplete and has hopefully no future.