warnings

[Adam Jackson]

-----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-----