modular -> monolithic

[Bernardo Innocenti]

Zack Rusin wrote:
> On Sunday 20 January 2008 14:20:34 Bernardo Innocenti wrote:
>> To summarize, it seems there's interest in merging the
>> drivers back into the server tree.
> 
> So here's my simple proposal on how to do it. 

Really neat!

A few comments below:


> I've used git submodule to create a complete graphics stack superproject which 
> basically takes all the modular parts and creates a monolithic tree out of 
> them.
> 
> One can check it out with:
> git clone git://people.freedesktop.org/~zack/seken
> (you'll notice the directories are empty so do:)
> git submodule init
> git submodule update
> 
> This will automatically checkout for you relevant projects.
> 
> So we get a monolithic tree from modular sources. Testers and developers alike 
> can easily checkout all relevant projects while others still have the option 
> of working only in the modular sources.
> 
> Toplevel directory gets a simple script or even a Makefile that compiles all 
> relevant sources and:

I'd use a top-level configure script instead, as in GCC.
Advantages are:

 - you save time by reusing test results from a common cache

 - you can pass options so that drivers can build against the
   server and proto headers without actually installing them

 - the top level confiugure could *search* for existing submodules,
   so that you'd not need to hardcode the list anywhere.

The gcc top-level configure does exactly this, and it can build
anything from just a bare C compiler to a full blown cross-toolchain
with all languages, binutils, debugger, newlib, simulator, etc.

Granted, few people understand gcc's configure machinery, but
they require fancy cross-compiling modes and a staged boostrap
process, and we don't.


> a) we can add -intel or -ati options that for example would build only sources 
> relevant to the intel driver (drm, mesa, xserver and intel driver parts), or 
> even slap something like kconfig in there,
> b) only maintained modules get added to the superproject
> c) developers making changes are required to assure superproject compiles 
> (which shouldn't be hard due to the fact that 1) all modules are maintained, 
> 2) there's an easy way to build all of them)
> 
>> 1) build time and build complexity
> 
> I think that works of the bat. If not then adding to the toplevel 
> script -xserver-drivers-only, -drivers-only, -drm-mesa-x-drivers options 
> would solve it and assure that developers who change only relevant parts can 
> change relevant parts. 

I couldn't agree more.  By keeping the underlying build process
and repository structure fundamentally modular, you implicitly
divide-and-conquer.

> Plus at this point a tinderbox with the superproject actually makes sense.

Indeed.

Moreover, a super-project approach like this elegantly solves the
FAQ "how do I build all the latest stuff?", for which the build.sh
solution always seemed a bit of a kludge.


>> 2) packaging
> 
> Is unchanged from the modular perspective. The only thing that changes is that 
> with superproject we can tag/branch all parts together. So distributors could 
> do: "git checkout xorg7.4" and automatically get all the modules xorg7.4 came 
> with, knowing they all compile and proceed to create package like he/she 
> would do from any autoconf project.
> 
>> 3) spreading the development burden
> 
> I don't think this adds a lot of burden on anyone. 

I was thinking to include all the crappy drivers in my
original proposal.

Now if we reach consensus that only those with active
maintainer(s) are going to be included, the problem is
implicitly solved.


> Maybe on one person who would maintain the superproject. It would be either 
> the release manager and if not then if there's interest in such a solution I 
> could be doing that.

Seems reasonable.


> So yea, it certainly wouldn't solve our problems but I think it makes a lot of 
> sense to have a super-project which at least tracks how do different branches 
> of different projects match. ("do i use Mesa 7.0.2 or HEAD with Xserver 7.2 
> and what version of the driver?" becomes "checkout xorg 7.2" and all 
> subprojects get the correct version)

I think this is *exactly* what we need to do.  Git-submodule
also support specifying branches, and we could use this to
easily drive new users to an easily buildable tree.

Thoughts?

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/