Add recipe for ada-url

[rHermes]

Hey, this is my first submission, so please bear with me 😅

I think I've followed all outlined requirements, the only one I'm insecure about is the "static" requirement. ada normally doesn't ship a dynamic library, it's only exporting headers and lib/libada.a. I don't know if this disqualifies it or not, but I needed this for my own purposes, and so I thought I would upstream this :)

I have not tested the windows build, but I hope the CI will.

Please let me know if you have any comments!

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.

[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/ada-url/recipe.yaml) and found it was in an excellent condition.

[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/12520530764. Examine the logs at this URL for more detail.}

[rHermes]

Hey! This package is ready for review @conda-forge/help-c-cpp, but I'm not sure why the linter is failing? I've followed the instructions given in: https://prefix.dev/blog/building_cpu_optimized_packages but I'm getting a linter error now.

[rHermes]

Ok, so I looked more into it and it seems that while the conda-smithy lint_recipe.py https://github.com/conda-forge/conda-smithy/blob/main/conda_smithy/lint_recipe.py#L253, does load the variant, while the github workflow script does not take into account this. Since it doesn't read this in, it doesn't have the context it needs when it's expanding the script.

I'm guessing this has no easy fix?

[rHermes]

So I managed to get the syntax past the lint checker, thought obviously it's not ideal.

[wolfv]

Hi @rHermes looks good to me! I think there is a slight bug in the linter code that I can take a look at on Monday and then we can hopefully merge.

[danielnachun]

Have you checked if passing -DBUILD_SHARED_LIBS=ON enables building a shared library? Strictly speaking -DBUILD_STATIC_LIBS=OFF should also be tried to see if it disables the static library.

[rHermes]

My interest in this is mostly to build this like a static library, so I have not played around with those options

[carterbox]

I think I've followed all outlined requirements, the only one I'm insecure about is the "static" requirement. ada normally doesn't ship a dynamic library, it's only exporting headers and lib/libada.a. I don't know if this disqualifies it or not, but I needed this for my own purposes, and so I thought I would upstream this :)

Our channel policy is that packages are shared by default and static optionally. e.g. You can ship the ship the static library in a separate output called "ada-url-static". From a cursory glance, it doesn't seem like there is a strong argument against having shared by default since there seems to be many bindings packages (for python, zig, lua, ...) which could reuse a shared library.