Add ARCHITECTURE.md

[hlopko]

In this file I hope to describe how we think about the architecture
of rules_rust. It's goal is to help contributors orient themselves, and to
document code restrictions and assumptions.

[hlopko]

Also r? @UebelAndre :)

[hlopko]

Comments and contributions are very welcome! This is just a first draft. I haven't written anything about many packages such as proto or bindgen.

[UebelAndre]

😄 Thanks for starting this! I think it looks good so far.

Does this mean you're looking to move ./util into ./rust/tools?

I'm also particularly curious about cargo. I think I like it as it's own package but I can also see it as part of rust/tools. Your thoughts?

[dfreese]

Looks like a solid start. Thanks for putting that together.

[illicitonion]

Looks good!

[hlopko]

Does this mean you're looking to move ./util into ./rust/tools?

Yup (or //rust/private/tools, depending on the tool, I haven't thought about where tools should go).

I'm also particularly curious about cargo. I think I like it as it's own package but I can also see it as part of rust/tools. Your thoughts?

If you're asking about cargo build script runner, I'm open to suggestions as I haven't looked into how it is used and how the rule using it works. If there's not strong reason why it should be in //rust, I'd vote to not put it there.

[hlopko]

So right now we say //rust is core package, everything else is less so. One alternative is to have a //contrib package that would contain all the "less so" packages. Opinions?

[UebelAndre]

If you're asking about cargo build script runner, I'm open to suggestions as I haven't looked into how it is used and how the rule using it works. If there's not strong reason why it should be in //rust, I'd vote to not put it there.

To my knowledge, the build script runner is there to run build.rs scripts which is a concept in Cargo, not rustc. So I think it makes more sense to leave it in the cargo directory. I think I like the existence of a cargo directory because it can act as the separation of cargo and rustc. Notably, #598 and #590 are also something I feel should go into cargo since they build on cargo manifests to generate Bazel repository definitions.

[damienmg]

If you're asking about cargo build script runner, I'm open to suggestions as I haven't looked into how it is used and how the rule using it works. If there's not strong reason why it should be in //rust, I'd vote to not put it there.

To my knowledge, the build script runner is there to run build.rs scripts which is a concept in Cargo, not rustc. So I think it makes more sense to leave it in the cargo directory. I think I like the existence of a cargo directory because it can act as the separation of cargo and rustc. Notably, #598 and #590 are also something I feel should go into cargo since they build on cargo manifests to generate Bazel repository definitions.

Yes cargo_build_script is named like this and in a different package because it is an interface with cargo not with the rust toolchain.

[hlopko]

I've created #601 and #601 to track cleanups relevant to this PR.