Module for vendored external Rust dependent code

[d3zd3z]

Origin

• aho-corasick
  • version: 1.1.3
  • repo: https://github.com/BurntSushi/aho-corasick
  • license: Unlicense OR MIT
• memchr
  • version: 2.7.4
  • repo: https://github.com/BurntSushi/memchr
  • license: Unlicense OR MIT
• regex
  • version: 1.10.5
  • repo: https://github.com/rust-lang/regex
  • license: Apache-2.0 OR MIT

Purpose

These are external modules needed to build the Rust support being integrated by #75904.

Mode of integration

These should be brought in as a module, perhaps rust-vendored. Maybe brought in as modules/lang/rust-vendored.

Maintainership

• d3zd3z

Pull Request

https://github.com/d3zd3z/zephyr-rust-vendored

Description

When writing Rust applications for Zephyr, the cargo build tool is able to bring external code in to resolve dependencies. Currently, the rust support as proposed in #75904 makes use of a few dependencies at build time. None of these dependencies are linked into the target image. It is likely for there to be a small number of additional modules needed, as the rust support is developed, but this will not grow unbounded. Dependencies added to a given application by the user will be automatically fetched by the cargo tool, and the user can decide for themselves whether or not to use the Rust/Cargo vendoring tools.

As there are a small number of these modules, covered by similar licenses, I have brought them into the same repository.

Dependencies

This code is used by the Zephyr code in lib/rust when Rust support is configured in and used. Having it in this tree prevents the rust build tools from fetching the code at build time.

Revision

2a677e6ab00b12a0d2d8308e04be109ee6868b8d

License

The external modules specify two license variants:

• MIT or Unlicense
• MIT or Apache 2.0

[d3zd3z]

I would like to propose an alternative to the vendoring of these modules, and instead argue that build-time Rust dependencies should be treated the same way that we treat python modules, using the language's provided tool for managing those dependencies. In the case of rust, that is the cargo tool.

If we have a requirement that the dependencies be downloaded as part of an initialization stage, the cargo fetch command can be used, although a small script would be needed in order to set up some paths. Cargo can be invoked to fail upon error instead of fetching dependencies.

Another approach is to use the cargo vendor command, which will fetch all of the dependencies, at once, and give some config file fragments that would use those instead of the online repository.

One important distinction is that it might also be necessary to add a script that verifies that there are no dependencies brought in through cargo that are being linked. In the case of Rust+Zephyr, the zephyr crate lib/rust/zephyr should only depend on local crates through its dependencies entry, although it, and those local crates are permitted to have build-dependencies that reference cargo provided crates.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.