GeezerVison

I would put the .devcontainer/README.md into docs/usingDevcontainers.md, maybe?

I would put the .devcontainer/README.md into docs/usingDevcontainers.md, maybe?

Seems good to me. One more thing, make sure to add a trailing line feed to files, so that the diff doesn't complain.

Oh, I thought that would be automatically done via the linter. Will do

Nevermind. The linter automatically removes trailing newlines... Is that intended?

Which linter are you using? clang-format should add trailing newlines, or at the very least not remove them. We mostly stick to having trailing newlines, and I think that almost all files already have them. (Keep in mind that clang-format is only for C/C++ files)

Well, I am using the standard linter integrated into the devcontainer. The linter automatically removes trailing endlines at the end of .json files.

Build size and comparison to main:

Question: what exactly is the correct compiler we are using? I need to specify the compiler "executable" for Intellisense

It's the one specified in the build instructions. https://github.com/InfiniTimeOrg/InfiniTime/blob/develop/doc/buildAndProgram.md

This pull request should be ready to merge now

Why are the checks failing? The logs imply a check called Compare build size is missing? I doubt that is intended behaviour?

This check depends on another check, but they can't be run because there are conflicts.

I have looked into extracting the compilerPath from build.sh. I do not see a way to do that currently. It was possible with the cmake extension for vscode since it allows to set a .sh script for setting up env variables. But the Intellisense (C/Cpp) Extension does not seem to support that sadly.
As far as I know this means either there will continue to be a possible desync of the two files or defines like the compiler, clang-format versions or paths need to be centrally defined in a .env file. In either case, that would be out of scope for this PR I think.

If anyone knows if there is way to set VSCode extension settings based on exported variables in a .sh script that would be ideal, I did not find a way.

Uh oh, I see the PR now has 176 changed files, did I mess up the merge...?
I merged all commits from main into my branch to get rid of the conflicts, why are all files that were changed on main now part of this PR?

@BloodStainedCrow I've just fixed that merge commit, so now I believe this pull request is in a good enough state to be squash merged.

I tried using the devcontainer again, and found a couple snags:

1. Building the devcontainer failed due to bad CRLF (docker wants LF) line endings in build.sh

2. Compiling failed because of bad CRLF (the container/python/src/displayapp/fonts/generate.py) wants LF) in src/displayapp/fonts/jetbrains_mono_bold_20.*

3. Connecting the OpenOCD debugger failed (silently rage) because of a missing dependency: libncurses5

4. and 2. were already known by me: I currently attribute them to me using WSL2 on Windows and Docker Desktop which is known to have some bugs leading to weirdness with line endings. If either someone else who knows a little about devcontainers (or me depends on who is faster) can test it on a Linux with docker machine and see if that changes anything.
   I presume changing the line endings on these files is a breaking change for some people and therefore not desired?

5. is simply fixed by adding the dependency to the dockerfile.

Additionally there does not seem to be any source mapping for debugging, I will have to look into that aswell

Okay, I have now found the correct setting to add source/symbol maps to gdb for debugging. As far as I can tell: pinetime-app-1.14.0.map is the correct symbol map. But gdb errors out with: can't read symbols: file format not recognized.
I was unable to find any info on using .map files with gdb so either I do not know what the correct symbol map file is, or I am missing something else. Is pinetime-app-1.14.0.map correct?

4. I currently attribute them to me using WSL2 on Windows

Indeed. The line endings however is due to git using the local encoding when you check out the repo (ie, in windows, so it gives them CR/LFs) but then when that repo is accessed inside the container all the tools expect unix textfiles.

So the actual repo doesn't contain any CR/LF files, they get converted to that when you check them out under windows.

We hit this when I was first trying to tackle the whole devcontainers thing. I think this comment provided the best general solution:

#1401 (comment)

Even Microsoft itself recommends setting eol=lf when working with devcontainers on Windows.

Another option could be to instruct Windows users to clone with --config core.eol=lf if they want to use devcontainers. > That wouldn't be seamless, but I suppose there really isn't any way to make this completely seamless (thanks Windows).

Ie, if you do the initial checkout in windows with eol=lf then it all works, and not doing so doesn't have any effects on those not using devcontainers.

Yikes, thanks windows indeed

@BloodStainedCrow could you recheck your open points with a LF checked out repo on WSL?

Both the failed container build and the failed compile are solved with this.

The only remaining problem I encountered is the missing source map/ symbol file for debugging.
Do you know which is the correct symbol file for gdb?

No problem, one question before I agree this can be merged:

The only remaining problem I encountered is the missing source map/ symbol file for debugging. Do you know which is the correct symbol file for gdb?

No problem, one question before I agree this can be merged:

The only remaining problem I encountered is the missing source map/ symbol file for debugging. Do you know which is the correct symbol file for gdb?

I don't sorry. Let's fix that in a separate PR 😁