Allow for a way to package and sign executables

[Jasper-Bekkers]

Problem

Right now cargo allows quite some configuration already when it comes to setting up a build, however, to support android (and iOS, and consoles) properly, it would need to have extensibility for two additional steps.

• Be able to package all build artifacts together into a single package (for example - an apk), a program would need to be able to be invoked with all the outputs of Tracking issues for the -Zmultitarget feature #8176
• Be able to sign the final output of that step, this could most likely be done in the same tool, so I'm just mentioning it here

Right now cargo-apk needs to perform these steps itself, however I would hope to eventually be able to get rid of cargo-apk as an intermediate tool and instead to be able to use vanilla cargo to be able to build and run apk's.

Proposed Solution

I propose an additional stage that runs after the linker which simply invokes a binary with the filename(s) for the previous (multi)target build. This tool should be able to generate a package, that can then be picked up by a (custom) runner.

Notes

No response

[Jasper-Bekkers]

It looks like this issue has been raised before in #545 and then in #8875, but it's unclear what steps forward would be required, or if help is even wanted/needed?

[joshtriplett]

We talked about this in today's @rust-lang/cargo meeting.

We've previously talked about adding post-build scripts for things like running the executable to generate completions, manpages, etc, and placing them in a dedicated directory that cargo install can then install. In theory, the same approach to post-build scripts could also allow building an apk or similar, and optionally signing it.

That does suggest that the design for post-build scripts needs to take the multitarget feature into account.

Any such post-build mechanism would need an RFC, and a fair bit of careful design. At the moment, we don't have the bandwidth available to do the design for post-build scripts, or even to iterate on a design for them with someone. That's not an indication that we'd be opposed to the concept, just that that would be a fair bit of new complexity that we don't currently have the bandwidth for.

We're going to close this in favor of #545. I've also added a comment to #545 referencing this, and noting that the design for post-build scripts would need to take multitarget into account.

[Jasper-Bekkers]

Any such post-build mechanism would need an RFC, and a fair bit of careful design. At the moment, we don't have the bandwidth available to do the design for post-build scripts, or even to iterate on a design for them with someone. That's not an indication that we'd be opposed to the concept, just that that would be a fair bit of new complexity that we don't currently have the bandwidth for.

@joshtriplett I totally understand bandwidth as a prioritization mechanism ;-), would there be a way in which we could contribute this and do some of this work ourselves, together with the cargo team. I'd be happy to invest into making this part of cargo quite a bit nicer to use tbh.