Use more recent version of libnice/GLib

[colatkinson]

Currently, the packaged versions of GLib and libnice are fairly out of date (glib==2.52.3, which was released in June 2017, and libnice==0.1.13, released in April 2015).

Is there a specific blocker as to why these versions are being used (e.g. some cascading dependency incompatibilities)? If not, I would be willing to attempt to update the packages, but I wanted to make sure doing so wouldn't inadvertently break things.

On a somewhat-related note, it appears that GLib is being built using a CMake build wrapper, instead of the vcpkg wrapper around Meson. Is there a reason for this? It seems like converting it could decrease maintenance overhead in the future.

[PhoebeHui]

@colatkinson, thanks for summit the PR!

[PhoebeHui]

Sorry to closed it by mistakes, Glib still doesn't upgrade, reopen it.

[colatkinson]

@PhoebeHui I actually totally forgot I included GLib as part of this issue. I'll make a PR to bring it up to date in the next couple days so that this can finally be closed.

[colatkinson]

So I've been attempting this, but have run into a few issues. For one, more recent versions of GLib have actually dropped the Visual Studio projects, as a part of their conversion to full usage of meson. The last version that includes these projects is 2.57.1, and this is thus the upper limit on what can be built using current methods.

The difficulty extends beyond just extracting the source lists, however. Meson has its own configuration directives, such as #mesondefine. Thus, the configuration headers in recent versions are incompatible with the CMake wrapper that vcpkg currently uses for building. I suspect that keeping the CMake wrapper up to date will become increasingly difficult, as there is actually a high amount of functionality included in the GLib meson build.

I think the best solution would be to use the native meson build configuration of GLib, as it could probably decrease the amount of downstream patching needed for a number of GNOME projects. I messed around with it a bit, but couldn't figure out how to get meson to recognize the build deps pulled in from vcpkg. There are a couple other packages that use meson builds (fribidi and libepoxy, specifically), but neither has any external dependencies.

If anyone has any views/advice on how to continue, please let me know.

May be related: #6683, #7129

[MVoz]

@colatkinson windows?

of course the code is not quite beautiful
but everything works
https://github.com/Voskrese/vcpkg/blob/7f22e7d266ca53c3be8212ce5508e7326f9de436/scripts/cmake/vcpkg_configure_meson.cmake#L85

dependencies are found

[colatkinson]

@voskrese Yes, this is on Windows. Unfortunately, I believe that meson depends on the pkgconfig binary existing, which I don't believe it does as a part of vcpkg? Please correct me if I'm wrong, as that would make the problem far simpler. If it does exist, meson can't find it.

Did not find pkg-config by name 'pkg-config'
Found Pkg-config: NO

I've actually made a bit of progress by patching the meson.build script to look for the vcpkg'd cmake modules, e.g. unofficial-gettext for libiconv. Unfortunately, there appears to be an upstream meson bug (mesonbuild/meson#5605) that results in my having to manually edit the unofficial-gettext-config.cmake file to remove the dependency on Threads. So I can continue to develop/test, but I can only get so far until meson upstream resolves that.

[MVoz]

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