search

tinygo-org / tinygo

Go compiler for small places. Microcontrollers, WebAssembly (WASM/WASI), and command-line tools. Based on LLVM.
https://tinygo.org
Other
15.42k stars 910 forks source link

[proposal] Support for machine/board Bundles #3362

Open ya-mouse opened 1 year ago

ya-mouse commented 1 year ago

Within a time we will have a significant number of supported machines/boards. This will bloat the base tinygo srcs.

Proposal

This proposal is about to split the machines-related code in "bundles". The existing code allows to merge regular Go sources and TinyGo (btw, src/os/exec/exec.go never being used with current implementation because os/exec is overriden by Go sources). The approach is to traverse bundles src directories and merge the contents with the TinyGo sources in the cached root. Same should be done for lib and bin if present. The per bundle targets should be merged separately.

Dependencies In order to support cross-bundle dependencies, it's possible to wrap the go install command to be called within bundle directory (set the GOPATH variable). The existing PoC should be re-worked to follow pkg-structure of Go packages.

Caching At the first implementation the targets being traversed each invocation and only missing symlinks are re-created. The bundle modifications (install, update, remove) should invalidate the existing cache.

The PoC that splits up the nrfx package: https://github.com/tinygo-org/tinygo/pull/3361

aykevl commented 1 year ago

This is a pretty drastic change. What's the advantage of this new system? Is there an advantage other than reducing the number of files in the machine package?

ya-mouse commented 1 year ago

I will split the change. The main part is for actual bundles support and the rest is files bouncing around. The advantage to move out machine/boards/targets out of main src tree.

aykevl commented 1 year ago

The advantage to move out machine/boards/targets out of main src tree.

Ah I see. In that case, I think the easier option would be to move the machine package as a whole out of the tinygo tree. This is something I've wanted to do for a while but it is rather difficult to do and would probably break backwards compatibility with existing code.

ya-mouse commented 1 year ago

The proposed change and working proof of concept do seamless merge of files for machine package and runtime as well. The bunch of files for machines are also there. With no backward compatibility breakage.

aykevl commented 1 year ago

The proposed change and working proof of concept do seamless merge of files for machine package and runtime as well.

I would very much prefer to not do that. We already do some merging of the Go standard library. We already have two variants (one with the syscall package and one without), and these variants are already troublesome for things like IDE support. Please don't introduce more variants for chip families.

ya-mouse commented 1 year ago

So, the only way is to move into separate packages out of the main tree? Then, the changes will not be back compatible. And things like uart from existing machine/runtime will require some extra init function to pass the machine's uart instance and so on.