Allow specifying paths to sub-commands

[dcsommer]

In my team's workflow, cargo and rustc are made available directly via the project's own Git repository. Those binaries in the repo are actually wrapper scripts that internally download, install, and call into the real binaries. Thus, all users of the build should depend on the cargo and rustc within the project repo. There doesn't seem to be a good way to specify the paths to these tools for all users of the project today.

In the rust-android-gradle's README, the only way to specify the paths for these tools is via local.properties (which is not checked in, so it doesn't help here), an environment variable (which seems to not be controllable from within a build.gradle file), or on the gradle CLI (which would be cumbersome and break existing workflows).

Would it be possible to add a fallback to reading gradle.properties just before relying on $PATH?

[ncalexan]

In my team's workflow, cargo and rustc are made available directly via the project's own Git repository. Those binaries in the repo are actually wrapper scripts that internally download, install, and call into the real binaries. Thus, all users of the build should depend on the cargo and rustc within the project repo. There doesn't seem to be a good way to specify the paths to these tools for all users of the project today.

An interesting approach. I guess you can use relative paths so that you don't see cross-platform path issues, and so that you can check in your paths? Tricky.

In the rust-android-gradle's README, the only way to specify the paths for these tools is via local.properties (which is not checked in, so it doesn't help here), an environment variable (which seems to not be controllable from within a build.gradle file), or on the gradle CLI (which would be cumbersome and break existing workflows).

You should be able to use an environment variable set from within your build.gradle, although you'd need to have it set Very Early (so that the plugin witnesses it at the right times) and you might run into issues with spawned JVM processes not inheriting it as you expect. (At least, I vaguely recall things like that.) You might want to arrange this in settings.gradle. And... now I remember that Java doesn't let you System.setenv.

Would it be possible to add a fallback to reading gradle.properties just before relying on $PATH?

How would you feel about allowing to set {cargo,python,rust}Command in your build.gradle? That feels simpler. I'm not 100% sure how to arrange it, I imagine we accommodate unset around here, but I'd have to experiment. I'd happily review a patch and documentation update.

[dcsommer]

How would you feel about allowing to set {cargo,python,rust}Command in your build.gradle

Yes, this would be perfect. I had thought of that approach earlier; not sure why I didn't mention it here! That's definitely cleaner than gradle.properties. I just need to be able to specify a project-relative path in these settings.

[ncalexan]

I have a patch in progress for this, should finish it up in the next day or two. Please ping me if it languishes!