Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split rust_library and add //rust:defs.bzl #592

Merged
merged 1 commit into from
Feb 19, 2021

Conversation

hlopko
Copy link
Member

@hlopko hlopko commented Feb 17, 2021

This PR splits 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.
  • rust_static_library: this will only provide CcInfo and it will
    represent an archive of all transitive objects, both Rustc-made and
    native.
  • rust_shared_library: this will only provide CcInfo and it will
    represent an shared library of all transitive objects, both Rustc-made
    and native.
  • rust_proc_macro: similar to rust_library, but with different
    crate_type passed to rustc and different validation logic for its
    attributes.

I this this makes sense based on these observations:

  • Right now rust_library covers all possible crate types except bin.
  • rust_library always provides CrateInfo, rust_libraries can depend on
    other rust_libraries.
  • When the crate type is cdylib or staticlib, rust_library provides
    CcInfo.
  • 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.

I believe smaller rules will make them less confusing and
will allow us to have more focused implementations.

This PR is mostly backwards compatible. //rust:rust.bzl#rust_library is
a macro. If the crate_type attribute is present, macro dispatches to
the right new rule. If it's not present, macro will choose the new
rust_library. New rules are added, so people can migrate at
their own pace.

defs.bzl is the bzl file that we now expect people to load. Bazel docs
recommend to store public rules in defs.bzl
(https://docs.bazel.build/versions/master/skylark/deploying.html#repository-content).

This change was first socialized at
https://groups.google.com/g/rules_rust/c/kGMg6haEF44.

Progress towards #591.

@hlopko
Copy link
Member Author

hlopko commented Feb 17, 2021

I started #591 to track the overall effort.

@UebelAndre
Copy link
Collaborator

Can you also make sure documentation is updated for this change?

@hlopko hlopko force-pushed the rules_split branch 2 times, most recently from 69be105 to c3c626a Compare February 17, 2021 20:56
@hlopko
Copy link
Member Author

hlopko commented Feb 17, 2021

Done. I think :)

Copy link
Collaborator

@UebelAndre UebelAndre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you'll need to fix the link to defs in docs/index.md I don't see that in this change.

Copy link
Collaborator

@UebelAndre UebelAndre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! Thanks!

This PR splits 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.
* rust_static_library: this will only provide CcInfo and it will
  represent an archive of all transitive objects, both Rustc-made and
  native.
* rust_shared_library: this will only provide CcInfo and it will
  represent an shared library of all transitive objects, both Rustc-made
  and native.
* rust_proc_macro: similar to rust_library, but with different
  crate_type passed to rustc and different validation logic for its
  attributes.

I this this makes sense based on these observations:
* Right now rust_library covers all possible crate types except `bin`.
* rust_library always provides CrateInfo, rust_libraries can depend on
  other rust_libraries.
* When the crate type is `cdylib` or `staticlib`, rust_library provides
  CcInfo.
* 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.

I believe smaller rules will make them less confusing and
will allow us to have more focused implementations.

This PR is mostly backwards compatible. //rust:rust.bzl#rust_library is
a macro. If the crate_type attribute is present, macro dispatches to
the right new rule. If it's not present, macro will choose the new
rust_library. New rules are added, so people can migrate at
their own pace.

defs.bzl is the bzl file that we now expect people to load. Bazel docs
recommend to store public rules in defs.bzl
(https://docs.bazel.build/versions/master/skylark/deploying.html#repository-content).

This change was first socialized at
https://groups.google.com/g/rules_rust/c/kGMg6haEF44.

Regenerate documentation

Regenerate documentation

Regenerate documentation

Regenerate documentation

Regenerate documentation
@hlopko hlopko merged commit 9aa4956 into bazelbuild:main Feb 19, 2021
PiotrSikora added a commit to PiotrSikora/rules_rust that referenced this pull request Mar 6, 2021
The ability to build Wasm libraries as executables is needed to support
WASI reactors (Wasm executables with multiple entrypoints).

This is a temporary workaround, and we should be able to use crate-type
"bin" when a proper support for WASI reactors (rust-lang/rust#79997) is
stabilised is Rust.

This feature was added in bazelbuild#312, and most recently broken in bazelbuild#592.

Signed-off-by: Piotr Sikora <[email protected]>
hlopko added a commit that referenced this pull request Mar 15, 2021
* Re-add support for building Wasm libraries as executables.

The ability to build Wasm libraries as executables is needed to support
WASI reactors (Wasm executables with multiple entrypoints).

This is a temporary workaround, and we should be able to use crate-type
"bin" when a proper support for WASI reactors (rust-lang/rust#79997) is
stabilised is Rust.

This feature was added in #312, and most recently broken in #592.

Signed-off-by: Piotr Sikora <[email protected]>

* review: sort.

Signed-off-by: Piotr Sikora <[email protected]>

Co-authored-by: Marcel Hlopko <[email protected]>
@hlopko hlopko deleted the rules_split branch April 1, 2021 07:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants