Theia rust embedded docker

[dwjbosman]

This docker container implements Theia, Rust and support for embedded development (ARM Cortex).

It contains the extensions as described in the embedded rust handbook:

• Qemu for ARM emulation
• OpenOCD for on target debugging
• The Theia eclipse cdt gdb plugin
• The VSCode cortex-debug plugin

A small demo project is available. This was tested using a STM32L152c-discovery board.

A big question is:

1. Do we want such specific Docker images in this repo?
2. If we do, then do we need to update repo organization (also see Re-organize repository folder structure #220)?

[marcdumais-work]

Hi @dwjbosman

• Do we want such specific Docker images in this repo?

Thanks to your good work to help limit the CI to mostly images that need rebuild/retest for a given PR, I think we can reasonably host more images. I think this new image you propose will be a good example, covering new ground for a Theia app vs what we have so far here.

My only general concern, adding more various images, is about longer-term maintenance - it might becomes difficult to maintain some of them (e.g. no volunteers that care enough). However we can mitigate this by having a process to remove unmaintained ones from CI and eventually remove them altogether from the repo, or alternatively move them in a "unmaintained" directory or such.

TL;DR: yes, this new image you propose is welcome in the repo

• If we do, then do we need to update repo organization (also see Re-organize repository folder structure #220)?

I think we should reorganize the repo as you suggest in #220, if possible before submitting your rust embedded image. I would be ok having both in the same PR, but separate commits.

├── docker/
│   ├── theia-cpp-docker
│   ├── theia-full-docker
│   ├── theia-rust-docker
│       └── general
│       └── embedded

I am not sure how you plan to handle the two rust images, but I would suggest that if you have common content used in both, you might have that stored in the theia-rust-docker root folder, and have variant-specific content in the subfolders.

[marcdumais-work]

@dwjbosman I'll look to borrow a device with which I can test this. From a quick search it looks like a RSP 2 or 3 have a Cortex CPU. Other than the board, do you know if I would I need other equipment?

[dwjbosman]

@dwjbosman I'll look to borrow a device with which I can test this. From a quick search it looks like a RSP 2 or 3 have a Cortex CPU. Other than the board, do you know if I would I need other equipment?

Hi, I think it should be a Cortex-M processor.

Most eval kits also contain an embedded programmer, so you can just connect via USB.

[marcdumais-work]

Hi @dwjbosman

I was not able to find an Cortex-M board to test-with. But I do not want to prevent this contribution from going-in. It's likely that the target audience will be relatively small, but still it's a nice example app.

So when you think it's ready to merge, just ping me and I'll approve the PR. In the meantime, you can consider:

• would it be better to keep this image as-is or factor-out parts that are the same as in the other rust image such that there is less redundancy? One advantage to each image being "standalone" is that we could more easily "retire" images that have become obsolete or unmaintained.
• whether you want to first re-organise the images in the repo (Re-organize repository folder structure #220) - I'm ok deferring this to after (it's not necessarily you that has to do this)

[vince-fugnitto]

Closing as the pull-request is quite outdated, and there hasn't been any recent activity.
We can re-open once it is updated.