modular -> monolithic
bernie at codewiz.org
Thu Jan 24 01:05:14 PST 2008
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.
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
> 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.
- 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
> Plus at this point a tinderbox with the superproject actually makes sense.
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
Now if we reach consensus that only those with active
maintainer(s) are going to be included, the problem is
> 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.
> 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.
|___| Bernardo Innocenti - http://www.codewiz.org/
\___\ One Laptop Per Child - http://www.laptop.org/
More information about the xorg