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

Refactor cargo-component internals and introduce proc-macro. #101

Merged
merged 14 commits into from Jul 28, 2023

Conversation

peterhuene
Copy link
Member

This PR includes a very large refactoring to the internals of cargo-component and how it works.

The biggest change is that cargo-component no longer generates an external bindings crate that is automatically added as a dependency to a user's component project. The motivation behind this change is that support for resources from the component model will preclude the ability to reference types from the user's crate because the export! macro is being removed.

Instead, component projects will need to reference the cargo-component-bindings crate to invoke the generate! proc-macro. This macro will expand to the bindings code based on the target world encoded from dependency resolution performed by cargo-component.

By default, the generate! macro will assume that the world / all exported interfaces are implemented by a type named Component, however that can be changed with an argument to the macro.

With the removal of the need for an external bindings crate, cargo-component no longer has a concrete reason to directly depend on the cargo crate as a dependency. Instead, it now spawns cargo for all subcommands that aren't built-in to cargo-component.

For this to function, cargo-component detects certain cargo options that may alter output (--verbose, --quiet, etc.) or what gets built (--manifest-path, --target, etc.). Before any unrecognized commands are passed to cargo, cargo-component will update the encoding of target worlds for bindings allowing commands that analyze or build the source code to work.

Additionally, cargo-component will recognize certain cargo subcommands that have outputs that need to be componentized.

As a result of these changes, about 150 crate dependencies were removed, the cargo-component executable shrunk about 12 MiB in size, and commands such as cargo component expand now "just work" without cargo-component having to provide its own implementation.

All dependencies, and the WASI adapters, are updated as part of these changes.

Note: the test command still isn't implemented.

Closes #97.
Closes #91.

This commit includes a *very* large refactoring to the internals of
`cargo-component` and how it works.

The biggest change is that `cargo-component` no longer generates an external
bindings crate that is automatically added as a dependency to a user's component
project. The motivation behind this change is that support for resources from
the component model will preclude the ability to reference types from the
user's crate because the `export!` macro is being removed.

Instead, component projects will need to reference the
`cargo-component-bindings` crate to invoke the `generate!` proc-macro. This
macro will expand to the bindings code based on the target world encoded from
dependency resolution performed by `cargo-component`.

By default, the `generate!` macro will assume that the world / all exported
interfaces are implemented by a type named `Component`, however that can be
changed with an argument to the macro.

With the removal of the need for an external bindings crate, `cargo-component`
no longer has a concrete reason to directly depend on the `cargo` crate as a
dependency. Instead, it now spawns `cargo` for all subcommands that aren't
built-in to `cargo-component`.

For this to function, `cargo-component` detects certain `cargo` options that
may alter output (`--verbose`, `--quiet`, etc.) or what gets built
(`--manifest-path`, `--target`, etc.). Before any unrecognized commands are
passed to `cargo`, `cargo-component` will update the encoding of target worlds
for bindings allowing commands that analyze or build the source code to work.

Additionally, `cargo-component` will recognize certain `cargo` subcommands that
have outputs that need to be componentized.

As a result of these changes, about 150 crate dependencies were removed, the
`cargo-component` executable shrunk about 12 MiB in size, and commands such as
`cargo component expand` now "just work" without `cargo-component` having to
provide its own implementation.

All dependencies, and the WASI adapters, are updated as part of these changes.

Note: the `test` command still isn't implemented.

Closes bytecodealliance#97.
Closes bytecodealliance#91.
@peterhuene
Copy link
Member Author

Additionally, this PR also refactors some of the cargo-component internals into a "core" crate.

This will allow for sharing implementation with cargo-component and the wit tool from https://github.com/peterhuene/wit (which I plan to merge into this repo shortly).

Copy link
Member

@sunfishcode sunfishcode left a comment

Choose a reason for hiding this comment

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

I'm not very familiar with the registry parts, but overall this looks good! My main concern is just how we can make the bindings module accessible to other modules:

README.md Show resolved Hide resolved
README.md Show resolved Hide resolved
README.md Show resolved Hide resolved
crates/core/src/progress.rs Outdated Show resolved Hide resolved
crates/core/src/progress.rs Outdated Show resolved Hide resolved
crates/core/src/progress.rs Outdated Show resolved Hide resolved
crates/core/src/progress.rs Outdated Show resolved Hide resolved
peterhuene and others added 8 commits July 26, 2023 13:47
Co-authored-by: Dan Gohman <dev@sunfishcode.online>
Co-authored-by: Dan Gohman <dev@sunfishcode.online>
Co-authored-by: Dan Gohman <dev@sunfishcode.online>
Co-authored-by: Dan Gohman <dev@sunfishcode.online>
Also update the example lock file.
This commit adds more context to when there's a problem creating the target
world.

It gives users a way of determining which cargo package is at fault for the
error when building a multi-package workspace.
@peterhuene
Copy link
Member Author

@sunfishcode thanks for looking this huge change over!

@peterhuene peterhuene merged commit e24c73e into bytecodealliance:main Jul 28, 2023
6 checks passed
@peterhuene peterhuene deleted the remove-cargo-dep branch July 28, 2023 00:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Notice: upcoming breaking change Support expanding bindings macro
2 participants