On 3 March 2015 at 12:15, Jose Fonseca <jfons...@vmware.com> wrote: > On 03/03/15 11:59, Emil Velikov wrote: >> >> On 3 March 2015 at 09:36, Jose Fonseca <jfons...@vmware.com> wrote: >>> >>> On 28/02/15 00:24, Rob Clark wrote: >>>> >>>> >>>> On Fri, Feb 27, 2015 at 5:05 PM, Emil Velikov <emil.l.veli...@gmail.com> >>>> wrote: >>>>>> >>>>>> >>>>>> - src/gallium/drivers/rbug: -- do people use it? does it work? it >>>>>> predates apitrace GL + GUI, which sort of enables a lot of the same >>>>>> things, but without the issue of having to hit moving target, which is >>>>>> what gallium interfaces are >>>>>> >>> >>> So it looks from the replies that rbug and rbug-gui is still useful. >>> >>>>> If we're going to keep this should we move the rbug-gui tool within the >>>>> mesa tree ? It would be nice to spare some of the "sigh... it does not >>>>> build" and let you guys just use it. >>>> >>>> >>>> >>>> >>>> +1 >>>> >>> >>> It sounds a good idea FWIW. I believe that rbug-gui depends on the >>> gallium >>> interface, and we don't maintain backwards compatibility, so moving it >>> rbug-gui into somewhere like src/gallium/tools/ and have it built by >>> default >>> should enable to keep it in sync more easily. >>> >> Indeed that was the reason I brought it up. >> >>> That said, integrating rbug-gui into Mesa tree is beyond my immediate >>> goals/needs. So I'll let those who do use rbug + rbug-gui to take that >>> task >>> on. >>> >> Ouch... did not mean to come across as "you should do it" or anything >> along those lines. > > > No prob. I just want to make sure that, by agreeing, I wasn't volunteering > :) > >> I'll need to read up a bit on how to preserve the >> history, but it's already on my list :-) > > > I tried to do that sort of "git-history-rewriting/spliting" acrobatics in > the past. And I have mixed feelings from my experience: being able to do > `git blame` on the new tree is indeed nice, but it's hard to get the history > right, in particular it's pretty hard to ensure that things build at > arbitrary commits, which can create troubles when bisecting (particularly > because there is no option for "git bisect --ignore-changes-in-this-path > src/gallium/tools/rbug-gui"...) > > The alternative would be to make http://cgit.freedesktop.org/mesa/rbug-gui/ > read-only, or just slap a big notice in description/read-me saying "this > code is unmaintained and moved to XYZ", import rbug-gui as a single commit, > and mention which rbu-gui commit this was taken from in the mesa commit > message. > As a learning exercise I've went ahead with the git filter-branch acrobatics. Afaict things should be perfectly bisect-able as I've intentionally removed the history of configure.ac and Makefile.in.
The whole thing seems to build like a charm, but I cannot get it running (something funny is happening between GTK and QT). Can someone give it a try ? The series can be found in branch rbug-gui-import at https://github.com/evelikov/Mesa/. Should I spam the list with the three patches first one of which adds 4000 lines of code ? Cheers, Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev