In general this seems a good thing to get integrated into KDevelop.

Though with the current documentation and a personal lack of experience on developing with Docker or flatpack, myself I am a little lost about the exact problems which should be solved by the new classes (even more as I yet have to grasp the build/execute parts of KDevelop completely). Pardon my ignorance so far.
Could you give some more concrete examples what does not work yet, and how the new classes and their functionality will be a solution?

E.g. extending the API dox of the new class IRuntime might help. The current text leaves me puzzled like this,to give you an idea where more explanation could help me and then perhaps some people:

A runtime represents an environment that will be targetted

What is meant by "environment" exactly? A set of environment variables? Another virtual or real machine? A chroot environment? Any of that? What not?
By what will the "environment" be targetted? Build system? Installation? Execution? Packaging? Deployment? Testing? Only one or any of them?

It allows the IDE to interact with virtual systems that live in different namespaces.

Is a "virtual system" such an "environment" or a "runtime"? Or just another term for it? What is a "different namespace" in that context?

It allows to execute processes in them and translate the paths these runtimes offer into ones that will be visible to our process to interact with.

This sounds like a runtime plugin would map between filesystem structures. But what defines which filesystem a process would expect? And by what principal logic would the mapping be done?
I would need an example at least to get an idea.

Please, also give a short comment what exactly can be seen in the videos, so one knows what to look out for and where to spot the differences. Some dialogs and actions are done so fast and without explaining why, so for the clueless watcher just some wild build stuff happens :)

In D5584#105032, @kossebau wrote:

Please, also give a short comment what exactly can be seen in the videos, so one knows what to look out for and where to spot the differences. Some dialogs and actions are done so fast and without explaining why, so for the clueless watcher just some wild build stuff happens :)

Okay, yes, sorry:

docker video

On the docker video you can see how the project cannot be tested in the local environment because some dependencies are not present. If you notice the first time it's run it complains that an import cannot be resolved. Then it's builds a Dockerfile that provides the package and when we choose the runtime it works transparently.
I think it's specially interesting that KDevelop takes care about how the file we are running is named within the docker, so it doesn't need special tinkering.

flatpak video

It opens ark, the KDE archiving software and directly fetches the dependencies (i.e this file) being libarchive and libzip. Then an environment is created with these, on top of KDE's flatpak runtime with all the dependencies ark needs to be developed. Then it builds and installs the ark version opened in the IDE against this environment. It's important because it gives us a generic 3-step fetch, build, execute procedure that any developer can use to develop KDE applications without having to worry about Qt/KDE/libzip/lib* versions.

first of all, sorry for the long delay Aleix. I haven't yet had time to look at the code, just watched your videos which look pretty neat. some high-level questions:

• would one need to build from scratch every time, or do you support some way to do partial rebuilds inside the container?
• did you actually manage to integrate the container environment into our language system? i.e. at work I'm working on one project inside a docker container that contains important thirdparty dependencies that are unavailable on my host system. in kdevelop, that leads to tons of "file not found" errors and so forth - how do you deal with that?
• you mention GDB, so we can build/run/debug transparently from kdev within a container with this patch?

In D5584#106860, @mwolff wrote:

first of all, sorry for the long delay Aleix. I haven't yet had time to look at the code, just watched your videos which look pretty neat. some high-level questions:

No worries!

• would one need to build from scratch every time, or do you support some way to do partial rebuilds inside the container?

Not really. It depends on the tech used of course but it works just fine here. Both for flatpak and docker (and obviously Android) allow to keep their build directory so it can just be re-used. The catch is that you want a different build directory per runtime, but I'd say that's a given.

• did you actually manage to integrate the container environment into our language system? i.e. at work I'm working on one project inside a docker container that contains important thirdparty dependencies that are unavailable on my host system. in kdevelop, that leads to tons of "file not found" errors and so forth - how do you deal with that?

That's the whole point of this approach, yes. And that's what the pathInRuntime/Host are supposed to achieve. (also see the kdev patch, it has some logic to translate include paths, although it's not working very well just yet, I'm assuming I'm failing to invalidate a cache somewhere).
For flatpak it should just work as the contained file system is easily available.
I haven't found a way to access the docker file system yet (without sshfs that is, which I consider a last resource approach).

• you mention GDB, so we can build/run/debug transparently from kdev within a container with this patch?

I haven't tested it yet, but it should just work as long as flatpak (which commonly does) and docker provide gdb. In this use case we'll still be triggering a process with which we can interact through the GDBMI protocol.

neat, sounds awesome - I'll try to find some time to try this out over the next days. But yes, without sshfs it's going to be tricky to get access to docker contents. I access them usually via, in my case, these paths:

/var/lib/docker/devicemapper/mnt/*/rootfs/

but, afaik, this only works for me as a normal user b/c I nastily allowed me access to that folder...

In D5584#106906, @mwolff wrote:

but, afaik, this only works for me as a normal user b/c I nastily allowed me access to that folder...

Correct. Figuring out docker would be a homeround surely. I looked into using /var/lib/docker but it's not available. We should probably get in touch with the upstream community and measure how open to dreaming they are.

Here's a video transparently switching from local to Android runtimes:
https://youtu.be/M7Hom4OUSHg