Resolve tools to include runfiles

[jsharpe]

Fixes #433

[google-cla]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[jsharpe]

@googlebot I signed it!

[jsharpe]

@oquenchil is there anything you'd like me to change to get this merged?

[UebelAndre]

A couple of questions/comments

[UebelAndre]

seems a bit odd. I'd expect $(execpath :make_tool) to be a path to the tool and target = ":make_tool" should be sufficient. Do you think it'd be difficult to update this to not require both target and path?

[jsharpe]

$(execpath :make_tool) is the output from a rules_foreign_cc build which doesn't generate an executable target directly ( you have to do the dance of creating a filegroup and an executable target via a wrapper or another cc_* rule. This issue is along the lines of the same problem that #428 is looking to address too; there may be multiple tools required in the PATH but I guess in the emscripten case that this could be done by a shell wrapper that sets up the path so that binaryen is present in the context that emscripten is expecting it to be.

Also note that I'd made this observation in the tool_access.bzl file that it'd be easier if this was an executable target than a freeform path as we need to special case between absolute and relative paths.

[UebelAndre]

One last question but I think it otherwise looks good.

[UebelAndre]

Is #490 related to this in any way?

[jsharpe]

Is #490 related to this in any way?

Not directly; but it'd be natural to fix up #490 after landing this.

[whs-dot-hk]

Good job, this is it... It will put an end to this repo

[UebelAndre]

Good job, this is it... It will put an end to this repo

Can you explain why you feel that way?

[github-actions]

This Pull Request has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days. Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_foreign_cc!

[github-actions]

This PR was automatically closed because it went 30 days without a reply since it was labeled "Can Close?"