Accessing the bundled file system

Christian Hergert christian at hergert.me
Mon Mar 20 20:43:03 UTC 2017


On 03/20/2017 06:48 AM, Aleix Pol wrote:
> I've been looking into what Flatpak support in KDevelop would look like.
> 
> I haven't seen any documentation on how file system access is
> envisioned. I might have missed the documentation, though.
> 
> So the idea is that the IDE should parse our source code using the
> runtime's includes (i.e. /usr/include/stdlib.h in the bundle rather
> than the host's). For docker, I've found they suggest using nsenter.
> Would it be possible to use that for flatpak runtimes? Or is there
> something ad-hoc planned?

One of my goals for an upcoming Builder release is to get libclang out
of process (and into a Language Server¹). That would simplify things as
the language server would have access to everything at the proper path.

This is something I'd like in the org.gnome.Sdk too, otherwise we'd have
to be tricky about compiling it or shipping a static binary. Neither of
which are ideal.

What we do today in Builder is to translate the paths using the OSTree
checkout. That means you have to translate all the $CFLAGS and $CXXFLAGS
for -I (which you have to do anyway to get libclang to load things
properly wrt relative paths, so it's just one extra step).

If the path starts with /usr, it gets translated to the runtime
deploy-dir. If it is /app, we use the files location created with
`flatpak build-init`.

To support profiling and debugging, you'll also need the .Debug runtime
variants and handle ELF symbol resolution for paths like /usr/lib/debug
to come from the .Debug OSTree deploy-dir.

-- Christian


¹
https://github.com/Microsoft/language-server-protocol/blob/master/protocol.md



More information about the xdg-app mailing list