I maintain a legacy embedded Linux application written in C++. The platform SDK is in the form of a Ubuntu 18 virtual machine housing the cross compile (ARM) toolchain. Code is checked out into VM to have all the tools available for compiling.
I've moved the toolchain into a docker container (based on Ubuntu 18) and volume mount the source code from the host. With this I can use VS Code as an editor and use the dev-containers extension to effectively work within the platform SDK environment with VS Code IntelliSense able to see all code and platform/SDK headers.
This has worked well until recently, with VS Code 1.86 phasing out support for older (glibc < 2.28) hosts.
I've tried to not run VS Code within the container, but to simply invoke the compile process provided by the container. This works but with a penalty, VS Code can no longer see the platform headers and so no longer provides IntelliSense and complains about unknown types, etc. I've considered 'exporting' the headers from the toolchain into my source tree for VS Code to reference, but this doesn't seem like a clean solution.
Researching this further, the preferred approach seems to be to update the toolchain container to a newer OS release so that dev-containers can be used. Without vender support though (product is long unsupported...) I'd have to puzzle through any issues so I'm yet to try this path.
Are there any other techniques out there I could employ to keep the legacy toolchain within docker but still allow VS Code IntelliSense to see the platform headers?
-- Update --
For the moment I've settled on the approach of having the toolchain within a container from where the build is run. To help with IntelliSense I've simply added a build target which copies the toolchain headers into a designated location in the mounted source which VSCode has been pre-configured to search. Does mean I need to run a 'prep' build setup before the editor is ready but otherwise works fine.