Splitting rust_library

[Marcel Hlopko]

Hi friends of Rust,

I'd like to hear your opinion about a change I'm considering.

Observations:
1) Right now rust_library covers all possible crate types except `bin`.
2) If the crate type is `cdylib` or `staticlib`, it provides CcInfo.

3) It always provides CrateInfo, rust_libraries can depend on other rust_libraries

4) when the crate type is `cdylib` or `staticlib`, Rust code will not be able to access the crate by `extern crate Foo` in the source; the behavior will be similar to depending on a CcInfo providing rule.

Proposal:

I'm thinking about splitting rust_library into multiple smaller rules:

* rust_library - rust_library will represent a non-transitive library similar to how cc_library, java_library and others behave. It will always provide CrateInfo, and depending on it will always mean you can access the crate from source. Once we support dynamic linking we can consider producing both rlib and dylib from rust_library, but let's leave that for another discussion.
* transitive_rust_library (I'm open to naming suggestions :) - this will only provide CcInfo and it will represent an archive of all transitive objects, both Rustc-made and native. I don't know if it makes more sense to have separate rules for static and shared libraries, or if just to have a rule attribute. Given how complicated cc_shared_library turned out it might make sense to anticipate complications and have separate rules.
* rust_proc_macro - just like a rust_library, but with a different crate type.

Rollout:
We can actually make this all work in a backwards compatible way. //rust:rust.bzl#rust_library will be a macro. If the crate_type attribute is present, macro will dispatch to the old behavior, if it's not present, macro will choose the new behavior. Other rules will be added, so people can migrate to them at their own pace. We could even provide an automated migration tooling based on buildozer. After some time (6 months?) we will make a breaking change and we will remove the macro and the old implementation.

I'm curious about your opinion on this. If we come to the conclusion that this is useful, I'll create a GitHub issue and will start working on changes.

Thanks!

--

Marcel Hlopko | Software Engineer | hlo...@google.com | 

Google Germany GmbH | Erika-Mann-Str. 33  | 80636 München | Germany | Geschäftsführer: Geschäftsführer: Paul Manicle, Halimah DeLaine Prado | Registergericht und -nummer: Hamburg, HRB 86891

[Damien Martin-Guillerez]

That looks reasonable to me.

For the name, why not simply `cc_rust_library` since it emits C++ providers?

--
You received this message because you are subscribed to the Google Groups "rules_rust" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rules_rust+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rules_rust/CAFuL9G%3DBW8bwm%3Drd%2BDjLYeLXNWcAOnLK5MnQmBxts24cemhDmQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Marcel Hlopko]

For the transitive ones? I actually am thinking about providing C++ providers from rust_library (different discussion :) but maybe to be symmetrical with C++ rules we can have 

rust_static_library
rust_shared_library

These sound better than _transitive_ to me. Wdyt?

[Damien Martin-Guillerez]

SGTM

--

--

Damien Martin-Guillerez

Software Engineer at Google

Legal stuff:

Google Germany GmbH

Dienerstraße 12

80331 München

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Geschäftsführer: Graham Law, Christine Elizabeth Flores

Diese E-mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind, leiten Sie diese bitte nicht weiter, informieren Sie den Absender und löschen Sie die E-Mail und alle Anhänge. Vielen Dank.

This e-mail is confidential. If you are not the right address, please do not forward it, inform the sender and erase this e-mail including any attachements.