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

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

On Thu, 2017-11-23 at 17:00 +0100, Sébastien Wilmet wrote:
> Hi,
>
> I've tried a little BuildStream, but I think I'll hit a problem if I
> don't use jhbuild anymore: have clang completion in my preferred text
> editor, it needs all the *.h files of dependent libraries. Currently
> those *.h files are either installed by Linux distro packages, or by
> jhbuild in the jhbuild install prefix, in all cases they are available
> on the host.
>
> With BuildStream the *.h files are inside the container, so I would need
> to run the text editor inside a bst shell to be able to access the *.h
> files and have C completion, if I understand correctly.
>
> When you need to hack on a C/C++ project with a text editor like Vim or
> Emacs, how are you doing it with BuildStream?

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 !

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.

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.

Cheers,
    -Tristan

[0]: https://gitlab.com/BuildStream/buildstream/issues/162