On Sun, Apr 18, 2010 at 7:45 AM, Mark Kettenis <span dir="ltr"><<a href="mailto:mark.kettenis@xs4all.nl">mark.kettenis@xs4all.nl</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> > From: Keith Packard <<a href="mailto:keithp@keithp.com">keithp@keithp.com</a>><br> > Date: Sat, 17 Apr 2010 21:17:28 -0700<br> <div><div></div><div class="h5">><br> > On Fri, 16 Apr 2010 21:57:47 +0200, <<a href="mailto:olafBuddenhagen@gmx.net">olafBuddenhagen@gmx.net</a>> wrote:<br> ><br> > > I don't see why other distributions can't provide something similar.<br> > > Even without true live bulids, IMHO this makes the whole point about<br> > > xserver being too hard to build pretty moot.<br> ><br> > Not really; except for Gentoo, all these kinds of builds ever see are<br> > somewhere along 'master', so you can't go get bits from some other tree<br> > and build those. We're stuck in a linear world right now, and I'd like<br> > to make more parallel development possible.<br> <br> </div></div>And really, if you want people to go beyond mere testing, and would<br> like them to contribute back code they pretty much have to compile<br> from a git tree.<br> <br> I just occasionally contribute code to X.org, but I'd like to do more.<br> However in many cases my attempts go a bit like this:<br> <br> 1. Update my checked out Xserver master tree. Realize that I had some<br> uncommitted fixes in there. Spend half an hour googling git<br> documentation how to recover from the fact that I now have a tree<br> with merge conflicts. (I don't use git on a regular basis).<br> <br> 2. Run configure for Xserver. Figure out that I need proto package X.<br> <br> 3. Checkout proto package X. Run configure, figure out that I need a<br> new macros package.<br> <br> 4. Run configure for Xserver again. Figure out that I need proto package Y.<br> <br> etc. etc.<br> <br> Typically by the time I've gone through the trouble of doing a dozen<br> of these iterations, I run out of time. When I come back at it a week<br> (or a month) later, I have to start all over again.<br> <br> So I very much *do* believe that reducing the number of git modules<br> needed to build the server will increase my productivity and increase<br> the number of diffs you'll see from me.<br></blockquote><div><br></div><div>Or you could use build.sh or jhbuild or moral equivalent. For testing, I have an entire X system checked out and use jhbuild to update it. It also automatically saves your work (via git stash) so you can deal with merge conflicts later. You also don't have to worry about hunting for dependencies and configuring those individually and manually.</div> <div><br></div><div><a href="http://wiki.x.org/wiki/JhBuildInstructions">http://wiki.x.org/wiki/JhBuildInstructions</a></div><div><br></div><div>It's non-trivial, but not terribly complex to set up. And once it's set up, you can pretty much forget about most of what's on that page. You just run jhbuild -f modular-buildrc build xserver or whatever and you're good to go.</div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div><div></div><div class="h5">_______________________________________________<br> <a href="mailto:xorg-devel@lists.x.org">xorg-devel@lists.x.org</a>: X.Org development<br> Archives: <a href="http://lists.x.org/archives/xorg-devel" target="_blank">http://lists.x.org/archives/xorg-devel</a><br> Info: <a href="http://lists.x.org/mailman/listinfo/xorg-devel" target="_blank">http://lists.x.org/mailman/listinfo/xorg-devel</a><br> </div></div></blockquote></div><br>