Re: GNOME Modulesets migrating to BuildStream - clang completion in text editor

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

Hi!

Quick handphone reply...

> On Nov 24, 2017, at 5:13 PM, Sébastien Wilmet <swilmet gnome org> wrote:
>
> > On Fri, Nov 24, 2017 at 03:16:09PM +0900, Tristan Van Berkom wrote:
> > Had not considered this use case yet, thanks !
> >
> > I'm an emacs user but have never used any kind of symbol completion
> > feature myself.
> >
> > For this, one could use `bst checkout` to get a full checkout of the
> > build outputs which your element (module) of choice depends on, and
> > then periodically delete / re-checkout your sysroot checkout when it
> > starts to get out of date (or make parallel checkouts for separate
> > projects).
> >
> > However currently this is a slow operation which uses a lot of disk
> > space. Since it is an export of the built artifacts, we dont risk using
> > hardlinks for the checkout, because that leaves the user in a position
> > where they can accidentally corrupt their local artifact cache.
> >
> > I have been considering adding some explicit switch like `--unsafe` to
> > the checkout command to allow users to do this "at their own risk", but
> > haven't really found a use case to justify this, maybe you just
> > provided one !
>
> As Christian explained, the text editor plugin also needs the list of
> CFLAGS, especially the -I's.
>
> With Meson the easiest is to read the compile_commands.json file created
> at the root of the build directory. See:
> https://clang.llvm.org/docs/JSONCompilationDatabase.html
>
> CMake can also create a compile_commands.json file.
>
> With the Autotools/make, the Vim plugin that I use provides a script to
> extract the CFLAGS while `make` is running:
> $ make CC='~/.vim/bin/cc_args.py gcc'
> this creates a .clang_complete file containing the list of CFLAGS.
> See:
> https://github.com/Rip-Rip/clang_complete/

In this case, most probably `bst shell --build` gets us closest, it will create a sandbox on the fly, 
containing the sources you intend to build, and fail if the dependencies are not yet built, but persist only 
for the lifetime of the interactive shell it spawns.

Same build environment that BuildStream will create for a build.

The functionality is all there but it sounds like we should carefully design the right interface for casual 
users and Builder users alike.

Cheers,
    -Tristan

> > Philip's reply is also a possibility but I would prefer recommending
> > something via BuildStream, mostly because you want to use exactly the
> > header files that you need for your target environment, but also
> > because there is no guarantee that a flatpak SDK will even have headers
> > for the dependencies you might want to use.
>
> Yes the Flatpak SDK doesn't contain all dependencies.
>
> > For the moment, I've added this issue[0] to make sure we dont lose
> > sight of this, in any case it should be very easy to implement.
> >
> > [0]: https://gitlab.com/BuildStream/buildstream/issues/162
>
> OK, it's a good news if it's easy to implement.
>
> --
> Sébastien