ajax at nwnk.net
Fri Sep 3 14:58:48 PDT 2004
-----BEGIN PGP SIGNED MESSAGE-----
On Friday 03 September 2004 13:50, Ray Lehtiniemi wrote:
> On Fri, Sep 03, 2004 at 01:15:50PM -0400, Adam Jackson wrote:
> > I would probably prefer that debrix only be used for developing the
> > autotoolery, and that debrix pull from the monolithic tree until such
> > time as the autotooled build process is felt to be sufficiently stable -
> > at which point we'd stop calling it debrix and start calling it Xorg.
> just grabbed a copy of debrix, and it seems to be only the
> xc/programs/Xserver subtree, correct? what happens to the rest of the tree
> when debrix becomes xorg?
Multiple meanings for the same word, unfortunately. Debrix means both the
modularisation project, and the core server component within that project.
The pieces are broken out individually where possible, eg in
debrix-input-mouse or debrix-extension-dbe or debrix-driver-ati.
The current major blocker is GL support, where we have lots of interdependent
code with no real clear way to split some of it apart. From memory, both
libGL on the client side and glx on the server side need common code, and
both GLcore and the client libGL require a Mesa tree to build, and anything
DRI-aware requires the libdrm headers, and... it's still a bit of a mess.
In principle you should be able to build the extensions from the inside out
(drm before dri, GLcore before glx), and you should be able to build a
GLX-aware libGL straight from Mesa. In practice we're not there yet. Also
GLcore needs to be replaced with a software renderer that looks like a DRI
driver, as phase one for teaching the X server to be a DRI client, which
would allow us to do accelerated indirect rendering (read: quake3 across
multiple cards using DMX).
The order in which these should be resolved is still an open question, and
perhaps not one that should be decided in advance.
> > I suppose that's Daniel's call to make though. I know Jakub Stachowski
> > has been doing some cool stuff in the debrix tree, but as far as the
> > source itself goes I'd rather not deal with cross-syncs.
> amen. with cvs it's pretty horrible. bitkeeper seems to be quite a bit
> better. not sure how tla handles things, i've not used it yet...
> are there plans to move all of x.org onto tla or bitkeeper at some point?
Definitely not bitkeeper, for the usual freedom reasons. Insert plug for "tla
star-merge" here; the problem being that no matter what SCM you use you're
still not going to be able to cross-merge between it (in debrix) and CVS (in
the monolithic tree), which you'll need to be able to do until the autotooled
build process is shaken down.
The problem as I see it is that switching from CVS is only worthwhile if you
switch away from CVS - note that subversion doesn't count as away from CVS -
but that doing so requires a serious mental shift on the part of the
developers. If we can't provide a decent cheat sheet for CVS users then we
may as well not switch, because we absolutely don't want to lose developers
- - ajax
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the xorg