modular -> monolithic
zack at tungstengraphics.com
Wed Jan 23 20:55:37 PST 2008
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.
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:
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.
Plus at this point a tinderbox with the superproject actually makes sense.
> 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.
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)
More information about the xorg