[wip] add an API to import an executable+runfiles

[hchauvin]

This PR implements #64. This is probably a work in progress concerning the API.

The feature here allows one to import to the scratch workspace an executable that was compiled outside of the scratch workspace.

The motivation is testing rules. @ittaiz it might be of interest to you because, for instance, it allows you to import the scala compiler for testing the scala rules. Having the download cache, this PR and copying all the *.bzl files is probably sufficient to have an integration test running.

[ittaiz]

I’m actually unclear about the motivation since bazel works with source dependencies and IIUC this means the scratch workspace doesn’t depend on this executable via source but on it’s outputs.
Is this only for better performance?
If I can copy the bzl files do I have to do the above?

@damienmg you also mentioned this feature, what scenario did you have in mind?

[ittaiz]

I re-read #64 and it indeed sounds like the main motivation is performance. I'm completely not belittling it but I want to understand if there are additional motivations?

[hchauvin]

One point, of course, is performance, because if you can avoid recompiling an executable for every one of your test cases, that could be great. This is not something that can be accomplished in general by just copying the runfiles of the binary to the workspace. (With the JVM, it's a bit simpler because jars are easier to move around, and you could imagine a java_import of a fat (deploy) jar.)

However, this proposal is also about convenience. With it, you don't have to import all the dependencies that you declare in the WORKSPACE, your BUILD files or your source files. You don't have to maintain a new way to build the executable just for your integration tests. In my opinion, it simplifies the writing of integration tests a lot.

It focuses on executables with runfiles because when you implement a rule for a language in Bazel, you often have a modified compiler laying around (to have a Bazel worker, for code coverage, to resolve file names). In integration tests, your goal is to check how this compiler behaves with your Skylark rules, so wouldn't it make sense to have this executable already built?