Support for VSCode devcontainers

[nscooling]

TL;DR

Adds support for docker-based interactive development using VSCode removing the requirement to install any tools locally.

See here for explanation of devcontainer with VSCode.

No breaking changes, purely an addition

Using VSCode and Docker

By adding the folder .devcontainer plus appropriate Dockerfile and devcontainer.json files, when opened using VSCode then a container is built specific to InfiniTime requirements.

Once running in the container, cmake can be invoked to build the appropriate executables. This means the host machine does not need any tools installing, just docker, VSCode and the VSCode extension Remote - Containers.

This has been tested on macOS, Win10 and Ubuntu.

Current Docker file

The current Dockerfile has been setup to explicitly download and install the required tools. This was done to simplify the Docker permissions model.

The tools are installed in /opt for script compatibility. the build.sh can be invoked from Linux/macOS invocations.

Further work TBD

1. There is still an issue with running bash scripts in the Win10 instance due to the classic ^M problem. dos2unix is part of the container but permissions are getting in the way
2. clang-tidy and clang-format are part of the image but are not being invoke using VSCode
3. The project is not using the VSCode cmake extension
4. Flashing the target through OpenOCD/J-Link from within the container

[pfeerick]

Would it be feasible to incorporate the dockerfile and build.sh into the main ones (and instead just link them to the folder), perhaps somehow behind a flag? So that we don't end up up with a bunch of dockerfiles and build.sh that diverge and need to be re-synced.

I haven't tried this yet, but I really like the idea, and looks like a good opportunity to try out the devcontainer feature.

[nscooling]

It should be, but not sure it's the right model. I deliberately kept them separate for now as the devcontainer dockerfile has slightly different requirements to the current default build one. It's mainly to do with interactive development and permissions. I didn't want to modify the one in the docker directory and I use that as my "check".

There is one benefit of keeping them separate, in that you can then use the devcontainer to experiment in a sandbox with different tools etc. (I'm trying out v10 of arm gcc locally) which you wouldn't need in the build dockerfile (e.g. clang-format, etc.). I'll experiment with whether I can use the build.sh from the docker folder instead of having a local copy (they are the same file, it's just the way docker builds and I'm copying the file into the container from the local mount).

Personally I believe it's better to keep the two dockerfiles separate (and accept the maintenance) but happy to try and merge them into one common file.

Let me know

[nscooling]

I've experimented this morning and I can't see an obvious way to not have this setup without moving all the stuff in the docker folder into the .devcontainer. It's just the restrictions on how devcontainer currently builds the container.

[JF002]

This looks like a nice feature from VSCode.
I can't test and maintain this feature, as I don't use vscode (I'm used to clion and don't plan on trying something else right now).
@nscooling can I count on you to maintain this feature and maybe improve it in the future, if necessary?

Are the 4 points you listed in Future work needed, or is this feature already usable right now?

[pfeerick]

Your issues with errors like $R not found when building the devcontainer stem from the fact the line endings of the shell script from were changed from LF to CRLF... either inadvertently by you or by f692754 not taking into account *.sh files as *.sh text eol=lf is missing.

Anyway, it's easy enough to tell VSCode to reapply LF instead of CRLF line endings, and then revert a lot of the changes made (because the shell script wasn't working) so that only the necessary ones remain... making the maintenance effort much easier ;)

This is working for me on Windows 10: https://github.com/pfeerick/InfiniTime/tree/devcon

.devcontainer/build.sh is unchanged from docker/build.sh... meaning you could use a filesystem link to just point to that file in docker/build.sh ... that is, if devcontainers supported the symlinks git creates :( ... which it doesn't. It b0rked itself when I just tried. Second copy of the file it is, but at least there's no changes to it.

[nscooling]

@JF002 yes I'm happy to maintain this going forward as I use it in all my work so have a vested interest in keeping it up to date and useable. I'll write a .md doc about building using devcontainers to help people try it out.

@pfeerick Thanks for the note and guidance - I'll address it; be useful to know whether you felt it is useful - I don't want to overload the codebase if I'm the only one who thinks this is cool!

[JF002]

Thanks @nscooling ! May I ask you to add a bit of documentation about this feature? Maybe just mention that devcontainer for VSCode is available in the project so that other people know they can use it.

[pfeerick]

be useful to know whether you felt it is useful

@nscooling Most definitely - it makes it possible for someone to quickly get a clean and containerised compile environment setup with VSCode as the front end... I see it as the perfect complement to the Gitpod option, and a more integrated way of using Docker and a decent free IDE.

[JF002]

I think you'll need to update the submodule for LVGL.
And that would be great if you could add a line or 2 about this in the documentation :)

[JF002]

@nscooling I'm sorry I neglected this PR for so long. Could you please fix the merge conflict and maybe add a bit of documentation about the availability of devcontainers for vscode (just so people are aware that you can use them with this project) ?

[JF002]

Those changes have been merged in #505. Thanks @nscooling for your work!