Skip to content

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

Merged
hlopko merged 1 commit into
bazelbuild:mainfrom
hlopko:rules_split
Feb 19, 2021
Merged

Split rust_library and add //rust:defs.bzl#592
hlopko merged 1 commit into
bazelbuild:mainfrom
hlopko:rules_split

Conversation

@hlopko

Copy link
Copy Markdown
Member

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
Copy Markdown
MemberAuthor

I started #591 to track the overall effort.

@UebelAndre

Copy link
Copy Markdown
Collaborator

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

@hlopko
hlopkoforce-pushed the rules_split branch 2 times, most recently from 69be105 to c3c626aCompareFebruary 17, 2021 20:56
@hlopko

Copy link
Copy Markdown
MemberAuthor

Done. I think :)

@UebelAndreUebelAndre left a comment

Copy link
Copy Markdown
Collaborator

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.

@UebelAndreUebelAndre left a comment

Copy link
Copy Markdown
Collaborator

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:mainFeb 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 <piotrsikora@google.com>
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 <piotrsikora@google.com>
* review: sort.
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Co-authored-by: Marcel Hlopko <hlopko@google.com>
@hlopko
hlopko deleted the rules_split branch April 1, 2021 07:48
Sign up for freeto 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

@hlopko@UebelAndre@damienmg