Add renode-cli

[MementoRC]

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 wanted to let you know that I linted all conda-recipes in your PR (recipes/renode-cli/recipe.yaml) and found some lint.

Here's what I've got...

For recipes/renode-cli/recipe.yaml:

• ❌ noarch packages can't have selectors. If the selectors are necessary, please remove noarch: generic.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/12979430354. 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/renode-cores/recipe.yaml, recipes/renode-cli/recipe.yaml) and found it was in an excellent condition.

[danielnachun]

Since build.sh here is mostly a wrapper dotnet publish, I'm wondering if rather than trying to patch that script, if we can just figure out the right dotnet publish commands and call those directly. This usually leads to a much simpler, easier to maintain recipe.

@danielnachun Please take a look at: #28944 - The recipe has some 'gcc' compilations that seem to integrate into DLLs, does that mean that it cannot be a noarch? Is dotnet that good of a magician?

I believe the native code originates from https://github.com/antmicro/tlib/tree/4a28cc4048ebcf4196a110218adff13253f1ba69. Normally I would say that we should build this as a separate package and make it a dependency. However, in this case that repository is untagged and is itself a maintenance fork of another untagged repository. Ideally we would built this a split package with tlib as a native package and recode-cli as a noarch package that depends on it. I don't have much experience making split packages but this one seems fairly simple.

Let me know if you have questions so far, and thanks for being flexible about how to do this. We're still figuring out how to handle .NET best in conda-forge so there's a lot of best practices that still need to be worked out, especially for more complex packages like this one.

[MementoRC]

Sounds good, but then I need to go back to the drawing board. I made a few split packages and will give it a try. I will ping the upstream maintainer to try to get a tag, they seem very thorough and conda-friendly - It's curfew over here, so I'll follow-up tomorrow

[danielnachun]

Great! I'll keep an eye on this issue in case you run into more challenges but this is great progress so far!

[MementoRC]

@danielnachun A little bit of butchering, but what are your thoughts so far? We can't split as rattler-build cache feature is experimental

[MementoRC]

@danielnachun Now would be a good time to peak-a-boo! I tried to add a dynamic library loader to the code to load the *.so from the various renode-cores in the renode-cli. I don't know if it works.
I don't know why the noarch triggers a non-unix build nonetheless, so it fails to build renode-cli on non-unix

[danielnachun]

This is looking better but I am still kind of concerned at the amount of patching and modifications we're making here. Some of this may be unavoidable, but right now this still seems difficult to maintain without a really deep understanding of this tool.

A couple thoughts so far:

• If we have to write a custom dynamic loader for the native core plugins just to get a noarch package, we should probably just accept this being a native package now. I wasn't aware of those plugins when I initially suggested trying noarch, but I would rather we just try to modify the code and build system as little as possible.
• Have you tried the dotnet publish command yet? I haven't had a chance to try it yet myself, but I'm thinking we'd need a lot less modification if we can just patch enough for that to work.

As I've mentioned before, this is a work in progress, but from what I've dealt with so far, things that are easy and reasonable to patch are:

• .NET version requirements
• Dependency versions if a version is outdated and causing a build to fail
• Forced usage of Mono on Linux and macOS

Making changes beyond those basic things runs a much higher risk of breaking automated updates. This weekend I will take what you have and try to simplify as much as possible. Thanks for your patience so far - I want to figure this out in a way that really makes it easy to maintain in the future!