warnings

[Ray Lehtiniemi]

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?




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



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

is debrix the main focus for the immediate future? what other large projects
are scheduled for inclusion in the near term?




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

ah, right.  i'll have to dig into tla at some point and get up to speed on
that model.



> 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 
> over it.

as a recent bk user, i understand completely :-)  i even still remember when
i switched from sccs to cvs, and that was years ago.  switching versioning
tools leaves lasting scars, no question.



-- 
----------------------------------------------------------------------
     Ray L   <rayl at mail.com>