warnings
Adam Jackson
ajax at nwnk.net
Fri Sep 3 17:38:47 PDT 2004
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Friday 03 September 2004 18:29, Ray Lehtiniemi wrote:
> On Fri, Sep 03, 2004 at 05:58:48PM -0400, Adam Jackson wrote:
> > 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.
>
> i see. this raises the question in my mind: is this the right time to be
> contemplating the major twiddling implied by something like xjanitor?
> should full-tree code tweaking be postponed until debrix settles down, to
> avoid creating unnecessary work for the debrix people? or is the debrix
> work primarily aimed at makefiles and such, treating the actual code files
> as opaque objects, for the most part anyway?
Opaque objects.
Let's clarify: there exists work in debrix beyond the autotoolery. However
the autotooled build bits can be hoisted out and the source tree repopulated
from the monolith. In this sense, the makefile bits treat the source as an
opaque object.
> > 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.
>
> is this diagrammed anywhere? i've used graphviz and dot with some success
> in the past to untangle this sort of thing... munch on the output of nm a
> bit, creating nodes out of .o files and edges out of symbol dependencies,
> and then start creating subgraphs for libraries and executables, plus extra
> subgraphs manually, until clusters emerge and the fog starts to clear..
Not that I know of. I find that looking for LoadSubModule in the code is a
pretty good way to tell at a large scale what modules depend on which other
ones. At a lower level, you really only find out by trying to break (what
you think are) independent pieces into their own build-time module. At
least, that's how I approached debrix.
> > 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).
>
> this is not sounding like "treating the code files as opaque objects"...
> unless some of the xjanitor cleanup would simplify your task? maybe the
> needs of the debrix people should guide the priorities of the xjanitor
> people?
I'm rambling by this point ;). Note that what I'm trying to do in replacing
GLcore is _remove_ code from the server. In that sense, it's not creating
debrix work, but rather making some debrix work transient; since we build the
DRI drivers from Mesa, if we build a fallback DRI driver, we no longer need
to worry about a GLcore module for debrix.
Which is why I later said it's not clear what order to do this in, I have no
real idea how difficult it will be to make a fallback-only DRI driver. I was
just mentioning (in probably too much detail) that the GL support code is
difficult and needs cleanup.
But I really do consider the source to be opaque from the perspective of the
build system.
> is debrix the main focus for the immediate future?
It is if people want it to be. The tired, poor, huddled Debian masses
yearning to run Xorg probably want it to be. The question is who else does.
Right now, "the debrix people" consists of Daniel, Jakub, and myself. The
build system proper is mostly just grunt work to get working; it's just that
no one else has stepped up to work on it. I'm not really interested in
hacking the build system, but I'll do it, because it needs doing. The work
would go significantly faster if we had more hands.
> what other large projects are scheduled for inclusion in the near term?
I can't speak to that for anyone besides myself. I will say that most of my
near-term projects involve improving life by removing code (bugs #400 and
#1245, destroying GLcore, ...).
I'm sort of indifferent as far as Xorg work breaking debrix' build system,
because it's already broken, it doesn't build a server that achieves feature
parity with the monolithic tree, no one's relying on it besides the debrix
hackers, and no one else - that I've seen anyway - has expressed any interest
in becoming a debrix hacker.
That, and making the build system work is for the most part a mechanical
process. The build system will take care of itself, because whichever one
people decide to use has to work. I certainly don't want to see code work
halted in favor of non-code work. Probably what will happen is we'll get the
new build process to a beta stage, then ask people to restrict their changes
to things that don't add or delete files or alter Imakefilery. Then
eventually, lock the xc tree to commits, blow away the debrix source,
repopulate from the monolithic tree, and dub the result the Xorg modular
build system.
- - ajax
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBOQ6XW4otUKDs0NMRAqPLAJ9rpVAteZW2QysWH8ggoKqYTag1DACdGkvP
Dnds03dA6tIyiTbXkG4JcBw=
=wSL5
-----END PGP SIGNATURE-----
More information about the xorg
mailing list