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-cli/recipe.yaml, recipes/renode-cores/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!

[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.

[MementoRC]

Wow, I solved it, dotnet was apparently still running or locking up some DLLs ... almost there

[MementoRC]

@danielnachun This may be a good point to give it another review. I tried to move to a single-file build, but for windows, I feared having to battle the .bat, so i redirect to a .ps1 - All arch are building and passing the tests. I made provision to separate the huge tests from the install files, it could easily be switched back if needed

@wolfv The tests framework is quite voluminous. In the original recipe, they are installed in the package folder (they used /opt), but I wonder if it is necessary to include them in the conda package since we are running the testsuite whenever we build

[danielnachun]

Things are looking really good now! I made a few more suggestions to consolidate/simplify patching. The only long term patching we'll have to carry for now is the changes needed to use dotnet instead of mono on Linux/macOS and the changes to disable building renode-cores inside of renode.

I'll leave it up to you if you want to open an upstream issue about those changes - they should really consider dropping Mono altogether, and maybe they would be open to adding a flag for users to skip building renode-cores automatically so that users can build it separately. But I don't think these changes need to be upstreamed for us to add the package to conda-forge.

[danielnachun]

Is the script this is patching still used in the build process? Usually .csproj files don't call shell scripts.

[MementoRC]

We do, there is an <Exec ...> into one of the .csproj that calls this, it assumes that it is a git repo and uses git ...

[danielnachun]

See my previous commend about the other information-version patch - if this Powershell script isn't being called by the build process, we don't need to patch it.

[danielnachun]

@danielnachun This may be a good point to give it another review. I tried to move to a single-file build, but for windows, I feared having to battle the .bat, so i redirect to a .ps1 - All arch are building and passing the tests. I made provision to separate the huge tests from the install files, it could easily be switched back if needed

@wolfv The tests framework is quite voluminous. In the original recipe, they are installed in the package folder (they used /opt), but I wonder if it is necessary to include them in the conda package since we are running the testsuite whenever we build

I think deleting large test files is definitely the right call here, especially since as you said the test suite is always run while building anyway. If a user really needs things from the test suite for developing some other piece of software, they can always download that from the repo directly.