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

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

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:

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/ gcc'
this creates a .clang_complete file containing the list of CFLAGS.

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.


OK, it's a good news if it's easy to implement.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]