Add libadwaita

[danyeaw]

Hey all, libadwaita is the GUI toolkit for the GNOME Desktop environment. Adding this library requires quite a lot of dependency coordination, since some of the dependencies aren't on conda-forge yet. One thing I was not sure about, is this ok to add libadwaita and its 5 dependencies in one PR? Otherwise we are going to have step by step add the tree dependencies, then add the branches, then add libadwaita.

This PR adds the following dependencies:

• libadwaita -> AppStream
• AppStream -> libxmlb
• AppStream -> itstool
• libadwaita - sassc
• sassc -> libsass-native

A few notes on patches:

• AppStream is Unix only since it uses autoptr which isn't supported with MSVC and also depends on libyaml which isn't cross-platform see Doesn't build on Windows ximion/appstream#231 and libappstream is not cross-platform anymore ximion/appstream#735.. I have patched out usage of AppStream by libadwaita on Windows since it is only used by a few of its features like the About Dialog.
• itstool which is patched to change from the Python libxml2 bindings (deprecated) to lxml based on the PR here: Switch from libxml2 to lxml itstool/itstool#57. I also pulled in a few other patches that some of the Linux distros are carrying until they make a new release.
• I changed libsass-native and sassc to use Meson instead of autotools for improved Windows support. For sassc, the build system is designed to download libsass and then download sassc in to the same project as a sub directory. Since making this separate dependencies is more conda-like, I was going to have to patch the visual studio project files to allow for this and I was also struggling to get libadwaita to find the dependencies since they had no pkgconfig files. Both of the projects are deprecated / archived, so there is no opportunity to upstream build system improvements and I think using Meson simplifies things for this use case. The meson.build files are from WrapDB.

Checklist

• Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml".
• License file is packaged (see here for an example).
• Source is from official source.
• Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged).
• If static libraries are linked in, the license of the static library is packaged.
• Package does not ship static libraries. If static libraries are needed, follow CFEP-18.
• Build number is 0.
• A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details).
• GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there.
• When in trouble, please check our knowledge base documentation before pinging a team.

[github-actions]

Hi! This is the staged-recipes linter and your PR looks excellent! 🚀

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/libadwaita/meta.yaml) and found it was in an excellent condition.

[danyeaw]

Depends on conda-forge/gtk4-feedstock#66.

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I failed to even lint the recipe, probably because of a conda-smithy bug 😢. This likely indicates a problem in your meta.yaml, though. To get a traceback to help figure out what's going on, install conda-smithy and run conda smithy recipe-lint --conda-forge . from the recipe directory. You can also examine the workflow logs for more detail.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/20629870960. Examine the logs at this URL for more detail.}

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/itstool/recipe.yaml, recipes/libsass-native/recipe.yaml, recipes/libxmlb/recipe.yaml, recipes/libadwaita/recipe.yaml, recipes/sassc/recipe.yaml, recipes/appstream/recipe.yaml) and found it was in an excellent condition.

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/libsass-native/recipe.yaml, recipes/appstream/recipe.yaml, recipes/libadwaita/recipe.yaml, recipes/sassc/recipe.yaml, recipes/libxmlb/recipe.yaml, recipes/itstool/recipe.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipes/libxmlb/recipe.yaml:

• ℹ️ The recipe is not parsable by parser conda-recipe-manager. The recipe can only be automatically migrated to the new v1 format if it is parseable by conda-recipe-manager.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/20650545695. Examine the logs at this URL for more detail.}

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/sassc/recipe.yaml, recipes/libxmlb/recipe.yaml, recipes/libadwaita/recipe.yaml, recipes/itstool/recipe.yaml, recipes/appstream/recipe.yaml, recipes/libsass-native/recipe.yaml) and found it was in an excellent condition.

[github-actions]

Hi! This is the staged-recipes linter and I found some lint.

It looks like some changes were made outside the recipes/ directory. To ensure everything runs smoothly, please make sure that recipes are only added to the recipes/ directory and no other files are changed.

If these changes are intentional (and you aren't submitting a recipe), please add a maintenance label to the PR.

File-specific lints and/or hints:

• .ci_support/build_all.py:
  • lints:
    • Do not edit files outside of the recipes/ directory.