Add Cargo Packager support #18
Conversation
|
I mentioned we could probably embed the resource files instead. I'm not fond of two different behaviors between debug and release. |
We can deal that separately I guess
Well, it is not different at all. We are just using resource resolver to resolve the resources in the build environment. But if we want to embed the files, we can do that later. |
Cargo.toml
Outdated
| @@ -37,6 +52,8 @@ crossbeam-channel = "0.5" | |||
| getopts = "0.2.17" | |||
| surfman = { version = "0.9", features = ["chains", "sm-angle", "sm-angle-default", "sm-x11", "sm-raw-window-handle"] } | |||
| winit = { version = "0.29", features = ["rwh_05"] } | |||
| # Cargo Packager | |||
| cargo-packager-resource-resolver = { version = "0.1", features = ["auto-detect-format"] } | |||
There was a problem hiding this comment.
I read the documentation of cargo-packager-resource-resolver and it seems it requires cargo packager.
I don't want any release builds being restrict to cargo packager only. Otherwise, other users won't be able to build their own release profiles. Is it possible we just access somewhere in release build? I saw there's resources tag mentioned above.
There was a problem hiding this comment.
Well, we must use any sort of packager out there to create bundles. So, it is just better to use cargo packager instead of 3 or more separate crates.
Otherwise, other users won't be able to build their own release profiles
Why? Cargo Packager is an open source project, and any user can just install it and build their own release profile.
I don't see any alternative as well as any reason against using cargo packager to be honest.
There was a problem hiding this comment.
Servo uses bundle manual commands in their mach scripts. There could be people want to build dmg all by themselves. And cargo package hasn't supported Flatpak yet which is a key format in verso's feature request issue. We should contain cargo packager metadata in Cargo.toml only.
I believe we don't need cargo packager to establish a CN cloud workflow for now. Just try to upload the binary as an artifact should be enough. We can worry about package format later.
There was a problem hiding this comment.
cargo-packager-resource-resolver does rely on cargo-packager's CLI. we could move it behind a feature flag to support custom build systems
| push: | ||
| branches: | ||
| - "*" |
There was a problem hiding this comment.
| push: | |
| branches: | |
| - "*" | |
| pull_request: | |
| branches: | |
| - main |
| @@ -37,6 +54,8 @@ crossbeam-channel = "0.5" | |||
| getopts = "0.2.17" | |||
| surfman = { version = "0.9", features = ["chains", "sm-angle", "sm-angle-default", "sm-x11", "sm-raw-window-handle"] } | |||
| winit = { version = "0.29", features = ["rwh_05"] } | |||
| # Cargo Packager | |||
| cargo-packager-resource-resolver = { version = "0.1", features = ["auto-detect-format"], optional = true } | |||
There was a problem hiding this comment.
I updated a commit that can embed all resource files into binary. I believe we don't need to handle file path then.
|
What ended up happening here? |
|
I think we can revisit this feature again. All we need to worry is bundling the resource directory together. |
|
I created an issue to follow the status: #85 Since the PR's base is pretty old, I created another branch for this and added @naman-crabnebula as a co-author. |
Enable the bundling of the Verso Browser using Cargo Packager.
cargo fmtis run to eliminate formatting issues.