Merged proto package

[Peter Hutterer]

On Wed, Apr 14, 2010 at 08:29:35AM -0700, Dan Nicholson wrote:
> On Tue, Apr 13, 2010 at 4:20 PM, Peter Hutterer
> <peter.hutterer at who-t.net> wrote:
> > On Tue, Apr 13, 2010 at 06:05:49AM -0700, Dan Nicholson wrote:
> >> On Mon, Apr 12, 2010 at 10:41 PM, Keith Packard <keithp at keithp.com> wrote:
> >> > On Mon, 12 Apr 2010 21:58:12 -0700, Keith Packard <keithp at keithp.com> wrote:
> >> >
> >> >> Eric had an additional suggestion this afternoon -- would it be crazy to
> >> >> consider merging util/macros and/or util/modular into this package at
> >> >> some point? Again, with the goal of making it easier to build the server
> >> >> or drivers, this would further reduce the potential necessary upstream
> >> >> bits.
> >> >
> >> > Yaakov commented on IRC that 'macros' is changing fairly quickly these
> >> > days, which would mean reving the unified package frequently. That seems
> >> > like a bad idea to me. Anyone else have an opinion?
> >>
> >> Yeah, macros is really it's own beast. If you wanted to merge macros
> >> and modular, I'd be OK with that. Something I've wanted to do for a
> >> long time is put some minimal autotools into modular and release it
> >> with accurate module lists for the katamaris. The idea being that the
> >> the question "How do I try the new X.Org release?" is easy to answer
> >
> > This is about the best use-case for git submodule that I've encountered so
> > far and I've used it quite extensively for 7.5 tinderboxing. It really
> > works nicely.
> >
> > The only thing lacking from git is to adjust the build order, so we still
> > need to resort to the build script. If git could take e.g. the submodule
> > order for the builds then that'd be perfect (looked into that once but
> > didn't get round to doing it).
> 
> I actually think our "build from git" story is pretty solid. 

I disagree, there's considerable opposition to use the build.sh script (for
various reasons, I personally find it does the job quite well). Having some
helper that allows git submodule foreach to be called as builder would be
awesome.

> However,
> there's a considerable contingent of people who don't want to get
> involved with unreleased sources, but rather see "X.Org-7.5 released"
> and want to give it a spin. Again, most of these people will get X
> from their distro when it gets updated, but I think it would be nice
> if there was an easy way to try the released X.Org on your own.
> 
> Just like how people will grab the vanilla kernel releases and test
> them out, I'd love to be able to have people run a script that spits
> out /opt/xorg-7.5 and let them test it. Or even me for that case just
> to see how a full X release fares rather than my mix of distro and git
> modules. It's pretty cumbersome right now to attempt this.

if you don't mind building X11R7.5 from git (instead of tarballs) you can
get the released versions:

$> git clone git://people.freedesktop.org/~whot/X11R7.5.git
$> cd X11R7.5
$> git submodule init && git submodule update
$> ./TINDERBOX /opt/xorg-7.5

this will get all sources released as part of X11R7.5 (and the ones from 7.4
that haven't been updated), check out the correct release tag and build +
install it. five commands only (you can repeat the last command on errors to
continue the build), not too bad.

It's the "build everything from master" that's more difficult to achieve
with git submodules than the released ones.

and the TINDERBOX script could take over the git submodule init and git
submodule update jobs too to make it even easier.

Cheers,
  Peter