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

2017-11-24 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Nov 24, 2017 at 03:16:09PM +0900, Tristan Van Berkom wrote: > 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 Sounds like you need to use reflink. Safe _and_ fast. Zbyszek

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

2017-11-24 Thread Tristan Van Berkom
Hi! Quick handphone reply... > On Nov 24, 2017, at 5:13 PM, Sébastien Wilmet 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

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

2017-11-24 Thread Sébastien Wilmet
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

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

2017-11-23 Thread Tristan Van Berkom
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

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

2017-11-23 Thread philip . chimento
The way I might approach it would be to install the appropriate Flatpak SDK and point the text editor plugin to /var/lib/flatpak/runtime/.../files/include. Regards, Philip C On Thu, Nov 23, 2017, 08:00 Sébastien Wilmet, wrote: > Hi, > > I've tried a little BuildStream, but I

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

2017-11-23 Thread Sébastien Wilmet
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

Re: GNOME Modulesets migrating to BuildStream

2017-11-10 Thread Tristan Van Berkom
On Fri, 2017-11-10 at 01:45 -0800, Christian Hergert wrote: > On 11/10/2017 12:46 AM, Tristan Van Berkom wrote: > > I'm sorry that out of the many things I have to juggle, I had never > > considered Builder compatibility to be a blocker for the GNOME release > > team to start maintaining GNOME

Re: GNOME Modulesets migrating to BuildStream

2017-11-10 Thread Christian Hergert
On 11/10/2017 12:46 AM, Tristan Van Berkom wrote: I'm sorry that out of the many things I have to juggle, I had never considered Builder compatibility to be a blocker for the GNOME release team to start maintaining GNOME builds in a new format, this does strike me as an unreasonable requirement.

Re: GNOME Modulesets migrating to BuildStream

2017-11-10 Thread Tristan Van Berkom
Hi Christian, When shaking the tree a bit more publicly, something was bound to fall out, lets figure this out. On my side, I can say that there is still a ton of work that needs to be done which can only be delivered after a hard switch to BuildStream for the GNOME modulesets - delaying this by

Re: GNOME Modulesets migrating to BuildStream

2017-11-09 Thread Christian Hergert
On 11/09/2017 03:20 AM, Tristan Van Berkom wrote: . This cut off wont happen in 2017, but will happen before the release of GNOME 3.28 stable. From now on, we will be creating the development releases using BuildStream. I'm all for seeing the BuildStream conversion happen. But I do have some

GNOME Modulesets migrating to BuildStream

2017-11-09 Thread Tristan Van Berkom
Hi All ! Following my earlier proposals (long[0], shorter[1]), our discussions with the release team in the unconference days of GUADEC, and some followup internal release team discussion[2], I'm proud to announce (with my spiffy new release team hat on) our intent to stop maintaining the