Feature request: applying icons to binary targets

[ebkalderon]

I would like to see support for applying icons to binary targets. Perhaps this could be added as an extra configuration switch under [[bin]]. If set, binaries targeting Windows would have the given icon file applied through a resource file, while Linux binaries could have a *.desktop file generated that could be placed in /usr/share/applications. I am not familiar enough with OS X to comment on how application icons are assigned to binaries.

I know that this feature is supported by CMake but is largely handled by the platform's available toolchain. Cargo can only interact with rustc AFAIK, so I presume we are limited by the capabilities of the compiler. How feasible would this be?

[alexcrichton]

This would probably be best suited as some form of post-build-system after Cargo. You're right in that Cargo largely just talks to rustc itself, and this sounds like it may not interact much with the compiler?

[ebkalderon]

@alexcrichton That is correct. For example, in Windows we would talk to MSVC instead of rustc. If not integrated into Cargo directly, then perhaps this functionality could be implemented as an installable subcommand for Cargo, much like cargo-fmt? I would like this functionality to be a part of the build system somehow, especially if we want our cross-platform story to improve.

[alexcrichton]

I think this could be easily integrated as a subcommand, yeah!

[ebkalderon]

I unfortunately don't have much knowledge about how Cargo works internally, so I don't know how useful I can be with implementation. However, I can certainly help with testing, especially on Linux.

Here are two reference links detailing how the *.desktop entry spec works on Unix-like systems:

• Anatomy of a Desktop File
• desktop-entry-spec - freedesktop.org

[GabrielMajeri]

The simplest way to add an icon seems to be through a resource file, and this could be handled through embed_resource. I'm not sure if this should be handled by Cargo with an icon field in Cargo.toml, or the end user.

As for the desktop entry, there seems to be a freedesktop_desktop_entry crate. Again, this could be handled either by Cargo (generated from Cargo.toml metadata) or by the end user.

@alexcrichton should these features be added to Cargo or kept external?

[alexcrichton]

If it's possible to do this via an external crate then that is best.

[epage]

As the discussion is focused on this being implemented via third-party support, whether an external subcommand or #545, I'm going to close as there isn't anything actionable for cargo itself. If there is a reason for us to re-evaluate this, let us know!