Re: IDE completion features and BuildStream [Was: Re: GNOME Modulesets migrating to BuildStream - clang completion in text editor]

[Christian Hergert <christian hergert me>]

On 11/29/2017 02:06 AM, Tristan Van Berkom wrote:
> In summary, some people like to use IDE features which give them symbol
> browsers and symbol completion features based on some introspection and
> context of what the user is editing.

Design-wise, flatpak and flatpak-builder have worked *really* well for 
us in Builder. So following their design will have the least amount of 
friction.

On that note, this is what I consider to have made our plumbing work so 
well together.

 * All building happens inside a mount/pid/etc namespace. Simply append
   a command after "flatpak build $options".

 * Ability to set a PTY FD when running said commands so we get proper
   VteTerminal integration in the IDE.

 * Simple set of rules to translate from paths inside the build
   namespace to the host, so that our libclang running inside the
   Builder flatpak runtime can access the headers for the target
   application. We will translate -I paths as appropriate using
   these rules.

   We also need a way to find the debuginfo files for the given
   libraries so that the profiler and debugger can decode symbols
   based on captured instruction-pointers/stack-frames.

 * Give us the location of the system includes so that we can inject
   those (generally just /usr/include or /app/include before translation
   into the SDK paths).

 * Handle "workspace" creation, dependency downloading, etc. But give
   us the option to disable what is allowed. We might need to prevent
   downloading on metered connections and such.

 * Don't expect us to do workspace cleanup. If the user closes Builder
   or it crashes, we should be able to re-use the previous workspace
   automatically.

 * Give us the ability to only build up to a given module, as Builder
   needs to be in control of incremental builds for the project itself
   using our build system abstraction.

 * Give us the ability to run a program inside the container which may
   need different settings than when building. We also will need access
   to a working gdb inside the container. We'll inject a PTY so that
   we can propagate output to a VteTerminal when the user is debugging.

 * Have a single file we can locate in the project tree that allows
   us to determine how to use BuildStream and configure our build
   pipeline to add the necessary BuildStream hooks.

 * Subprocess launching needs to be fast, so we can't be blocking
   on exploding a file-tree every time. Also, side-effects must exist
   across subprocess launches.

Anyway, that is what comes to mind currently. I expect most of it won't 
take anything special on BuildStream's part.

-- Christian