chore: Replace acap-build crate with external rs4a-eap - #239
chore: Replace acap-build crate with external rs4a-eap#239apljungquist wants to merge 2 commits into
acap-build crate with external rs4a-eap#239Conversation
Remove the in-tree `acap-build` crate and depend on the `rs4a-eap` crate from apljungquist/rs4acap instead. This has benefits in two categories: - Clarifies the purpose of this repo as facilitating the use of Rust in ACAP app implementations - `rs4a-eap` has several implemented and planned improvements, notably the option to not depend on external programs allowing it to be fully installed with cargo, and more robust testing. We drop all use of the reference implementation, which rs4a does not support and instead rely on the testing done by the library maintainer (me). The approach was flawed anyway since bugs could creep in when staging files in a temporary directory.
| .args(args) | ||
| .artifact_dir(get_cargo_metadata(None)?.target_directory.join("acap")) | ||
| .execute()?; | ||
| .execute(cli.source_date_epoch.unwrap_or_default())?; |
There was a problem hiding this comment.
This doesn't actually match the docstring:
Defaults to the current time.
I need to fix that.
I may move the interpolation into execute or some other shared location.
acap-build crate with external rs4a-eap
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
guoxe
left a comment
There was a problem hiding this comment.
I'm not against this change. Especially as more parts of the ACAP SDK gets added it would be nice to focus on only the wrappers and example applications and having any additional tooling live elsewhere.
This way, the focus of this repo is clearer and there is really nothing that requires one to use the extra tooling either, using cargo and existing ACAP tools works just as well as the experimental ones.
| Completions(CompletionsCommand), | ||
| } | ||
|
|
||
| fn parse_mtime(s: &str) -> anyhow::Result<Mtime> { |
There was a problem hiding this comment.
Might be worth DRYing this since to me it does not seem like we would want the implementations to diverge.
Note
This is still work in progress, I still want to land a few more changes in rs4a and publish the crate.
That said, early feedback is welcome, in particular on issues such as:
Remove the in-tree
acap-buildcrate and depend on thers4a-eapcrate from apljungquist/rs4acap instead. This has benefits in two categories:rs4a-eaphas several implemented and planned improvements, notably the option to not depend on external programs allowing it to be fully installed with cargo, and more robust testing.We drop all use of the reference implementation, which rs4a does not support and instead rely on the testing done by the library maintainer (me). The approach was flawed anyway since bugs could creep in when staging files in a temporary directory.
Footers
Related-to: #205 (abandoned attempt at not shelling out to
cp, a problem that does not affectrs4a-eap)