Add subcommand to cleanup images?

[Alexhuszagh]

Checklist

• I've looked through the issues and pull requests for similar request
• This feature could be solved with a custom docker image (optional)

Describe your request

Currently, users have to be proficient with docker or podman to cleanup images, when we should be able to remove any installed images if desired from a cross subcommand.

For example:

cross remove-images

This would then filter for all images starting with ghcr.io/cross-rs, and rustembedded/cross, and then remove all the matching images. We could also accept a list of targets, or empty for all, to remove all matching targets. For the former, we would want to filter for those matching main or edge, to avoid removing local images.

For example:

cross remove-images aarch64-unknown-linux-gnu arm-unknown-linux-gnueabi mips-unknown-linux-gnu

We could probably at the same time provide a list-images subcommand, to list what images have been previously installed, using the same syntax.

$ cross list-images
aarch64-unknown-linux-gnu
arm-unknown-linux-gnueabi
mips-unknown-linux-gnu

Describe why this would be a good inclusion for cross

This would further simplify using cross as a "zero-setup" cross-compilation tool, and also avoid users having to manually cleanup numerous images or write a script to automatically remove all images to reduce the storage requirements of cross.

[Emilgardis]

I think to avoid clashes with cargo (not likely), this should be a cross-dev tool, I've been thinking about something for that with gated features to also replace the bash scripts (that are used in CI)

[Alexhuszagh]

I think to avoid clashes with cargo (not likely), this should be a cross-dev tool, I've been thinking about something for that with gated features to also replace the bash scripts (that are used in CI)

That sounds good, so that would also work for the target info and build-docker-image.sh or so? I think probably cross-dev maybe should just be for maintainers though, and we should have another tool for client utilities/extensions (like what's mentioned here)?

[Emilgardis]

That sounds fair.

We can bundle the extra tool with a [[bin]] target. Maybe cross-util?

[Alexhuszagh]

I think that sounds perfect. I'll start migrating things over after I finish the workspaces stuff, which I think has higher priority.

[Emilgardis]

Actually, I don't think the build script should be replaced with a rust program, we should instead use a docker bake definition (which can possibly be improved with a rust program).