Unbundling dependencies

[dgcampea]

libmpdclient is built with meson and provides a pkg-config file that could be used here instead of having to maintain a custom cmake module and a copy of the dependency under dist/.

[jcorporation]

myMPD uses a patched libmpdclient and that’s why it is bundled. The libmpdclient in distributions is too old.

Most of the patches are for features from MPD 0.24 and are waiting to be merged in upstream.

https://github.com/MusicPlayerDaemon/libmpdclient/pulls

This was already discussed in #874.

[jcorporation]

I think bundling the compressed woff2 file as asset is the best. I already added the compression workflow to the build script. #991

I know no distribution that provides the material icons font as package, or is that not true?

[dgcampea]

I know no distribution that provides the material icons font as package, or is that not true?

I see a few results in https://pkgs.org/search/?q=material-icons. I presume NixOS, Guix and similars do so as well.

[jcorporation]

They bundle the ttf or otf files, but not the woff2 files.

https://fedora.pkgs.org/37/fedora-aarch64/material-icons-fonts-4.0.0-7.fc37.noarch.rpm.html

[dgcampea]

They bundle the ttf or otf files, but not the woff2 files.

Hence why woff2 would be the second dependency, to invoke woff2_compress on it.

Note: woff2_compress places the file in the same directory of its argument, contrary to the expectations of placing it in the current working directory. It will have to be copied/symlinked to the "build directory" and compressed there.

[jcorporation]

Another problem is, that the ligatures.json is not created from the woff2 file, but from an google api endpoint. The woff2 file and the ligatures.json must be in sync and distributions tend to deliver outdated files.

I do not like the idea, it adds too much complexity.

[dgcampea]

Another problem is, that the ligatures.json is not created from the woff2 file, but from an google api endpoint. The woff2 file and the ligatures.json must be in sync and distributions tend to deliver outdated files.

Can't ligatures.json be generated from a offline-only machine? I haven't read the source carefully but I'm aware that ligatures.json was handled by the build script.

I do not like the idea, it adds too much complexity.

If putting this machinery as optional or is too complex to be worth it then we can just leave things as is.

[jcorporation]

I use the metadata provided by Google because they group the ligatures in categories. This is not possible with woff2 file only.