[librsvg] Update to 2.40.23

[ADKaster]

This is a special "for gtk" backport release that doesn't require rustc

librsvg was added as a dependency of GTK in gitlab.gnome.org/GNOME/gtk/-/merge_requests/8541.

The initial commit gitlab.gnome.org/GNOME/gtk/-/commit/939bf2544914262ab1371e73a4d9a3518dfb6efd depends on 2.60, which requires rust. A follow up (from the same MR?) added a fallback for a backported version of 2.40 gitlab.gnome.org/GNOME/gtk/-/commit/afa0d2341a442d356f91ee0a9f7b168cf14d628a.

The backported version, based on the librsvg-for-gtk branch is tagged as librsvg-gtk-2.40.3 in the librsvg git repo.

Outdated

Unfortunately, some of the checked-in generated files that the librsvg port seems to have been relying on have been removed from the git repo, so I had to add rules to generate them manually, based on the project's Makefile.am. The project's meson.build still does not generate pkgconfig files in that version, though surely patching meson.build to add them would be a better idea going forward rather than my patch. But whatever. It seems clear that the special backport version is only there for systems/ditros/package managers without rust support to keep building gtk latest.

A new patch modifies the project's meson.build to add 3 features:

• Install header files, including generated headers
• Apply .symbols/.def file to windows builds to properly mark DLL export surface
• Generate pkg-config file

Split from #47040

• Changes comply with the maintainer guide.
• SHA512s are updated for each updated download.
• The "supports" clause reflects platforms that may be fixed by this new version.
• Any fixed CI baseline entries are removed from that file.
• Any patches that are no longer applied are deleted from the port's directory.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is added to each modified port's versions file.

[ADKaster]

I ran into #48350 testing this locally on Windows. I doubt that gdk-pixbuf, librsvg and pango are the only affected projects.

[vicroms]

Unfortunately, some of the checked-in generated files that the librsvg port seems to have been relying on have been removed from the git repo, so I had to add rules to generate them manually, based on the project's Makefile.am.

Marked as requires:vcpkg-team-review to discuss this change.

[ADKaster]

Marked as requires:vcpkg-team-review to discuss this change.

The newly required generated files are librsvg-features.h, using a simple configure_file, and the invocation of glib-mkenums here using the python script I added.

The source tarballs from https://download.gnome.org/sources/librsvg/2.40/ have the files librsvg-enum-types.{c,h} and librsvg-features.h included.

The change to use a "non-released" tag requires that these files be generated by the build instead.

As noted in the PR description, tags based on the upstream branch "librsvg-for-gtk" is required to support the newest versions of GTK. GTK 4.19+ nominally takes a dependency on librsvg 2.60+. librsvg moved to a rust implementation in version 2.41. The branch "librsvg-for-gtk" has produced two tags librsvg-gtk-2.40.22 and librsvg-gtk-2.40.23 as a fallback for distributions/systems/etc that do not want to take the rust dependency cost.

The file generation using glib-mkdenums is a replacement for these lines in Makefile.am: https://gitlab.gnome.org/GNOME/librsvg/-/blob/librsvg-gtk-2.40.23/Makefile.am?ref_type=tags#L189-L216

I discussed the generated files a bit with @dg0yt in #47040 (comment). After fiddling with trying to wrangle CMake add_custom_command lines for the glib-mkenums invocation in a way that doesn't choke when run through cmd.exe, I cut my losses and used a python3 script instead.

[BillyONeal]

The file generation using glib-mkdenums is a replacement for these lines in Makefile.am: https://gitlab.gnome.org/GNOME/librsvg/-/blob/librsvg-gtk-2.40.23/Makefile.am?ref_type=tags#L189-L216

Why is it adding a separate python script to do that rather than doing it directly in CMake as is done in upstream's build system? It looks like the Python script is just invoking another program...

This is a special "for gtk" backport release that doesn't require rustc

Does the real release need only rustc or does it also need cargo? The problem with rust dependencies has always been cargo, not rust itself. (We have Fortran dependencies after all even though that creates problems)

[BillyONeal]

The file generation using glib-mkdenums is a replacement for these lines in Makefile.am: https://gitlab.gnome.org/GNOME/librsvg/-/blob/librsvg-gtk-2.40.23/Makefile.am?ref_type=tags#L189-L216

Also could we just use upstream's build system with that Makefile.am or similar rather than making our own replacement?

[vicroms]

The project's meson.build still does not generate pkgconfig files in that version, though surely patching meson.build to add them would be a better idea going forward rather than my patch.

The file generation using glib-mkdenums is a replacement for these lines in Makefile.am: https://gitlab.gnome.org/GNOME/librsvg/-/blob/librsvg-gtk-2.40.23/Makefile.am?ref_type=tags#L189-L216

@BillyONeal @ras0219-msft and myself discussed this during our weekly meeting:

We should try switching to an official build system, i.e. Meson; we believe that our support for Meson has improved substantially since this was first packaged. Plus, we are more comfortable taking a script that generates pkgconfig files from the build output rather than one that generates product code.

[ADKaster]

Why is it adding a separate python script to do that rather than doing it directly in CMake as is done in upstream's build system? It looks like the Python script is just invoking another program...

I tried to explain this in my comments, but the answer is "I tried and failed". I could not massage the strings to behave in both linux and windows shells to invoke the glib-shipped glib-mkenums tool properly. That tool used to be a perl script in time immemorial, but these days is a python script.

To clarify, upstream does not have a CMake build system. it has an autotools one (for shipping) and a meson one (for local builds). Sometime after 2.40, it appears that the meson build was promoted to 'for shipping'. As such, upstream does not have pkg-config goo in the meson.build at the 'rustless for gtk' latest tag.

Does the real release need only rustc or does it also need cargo? The problem with rust dependencies has always been cargo, not rust itself. (We have Fortran dependencies after all even though that creates problems)

https://gitlab.gnome.org/GNOME/librsvg/-/blob/2.61.3/meson.build?ref_type=tags#L25

The upstream meson build for the latest tagged release invokes cargo (through a wrapper script apparently?) for the rust internals. It has a C-API wrapper for the rust lib.

https://gitlab.gnome.org/GNOME/librsvg/-/blob/2.61.3/rsvg/meson.build?ref_type=tags#L86-L103

We should try switching to an official build system, i.e. Meson; we believe that our support for Meson has improved substantially since this was first packaged. Plus, we are more comfortable taking a script that generates pkgconfig files from the build output rather than one that generates product code.

Will do, I'll poke at the meson build and see if it can be massaged into a vcpkg port.

[ADKaster]

@BillyONeal @ras0219-msft @vicroms can this be put back in the review queue?

I've changed the patch to do these things:

• pull from a github mirror to grab the specific branch we need. grabbing the branch from gnome gitlab hits the Anubis issue that was previously worked around by grabbing tarballs from the release ftp mirror thing.
• remove the CMake build system
• use the provided upstream meson build
• add a patch to the upstream meson build to add 3 missing features:
  • install headers
  • create the windows .def file from the provided .symbols file. Previously, the CMake build did not create a version script for Unix. Upstream latest (ft. rust) does do this, but I decided to keep parity with the previous vcpkg build.
  • create the package-config file

[vicroms]

Thanks for the PR!