Accessing the bundled file system

[Aleix Pol]

On Mon, Mar 20, 2017 at 9:43 PM, Christian Hergert <christian at hergert.me> wrote:
> 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.

I've been thinking about it for a bit, the daemon has been part of
discussions for years now on our side. I can expect on yours too.
I wouldn't want to put all our hopes and dreams into having the server
working though, especially when we have a fully disjoint working
implementation nowadays. Also I don't see why it wouldn't work with
the normal libclang usage, as we need to feed it the include
directories anyway. We "just" need to have them visible from
KDevelop's process, which we need anyway if we want to be able to view
the files.

> 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.

Communicating with gdb from within the bundle (AFAIR, gdb is part of
the freedesktop.Sdk anyway) should be easy anyway, as the
communication is through the protocol rather than binary linking.

Aleix