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/ > 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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
