Sounds like the Mesa directory re-org should happen sooner, rather than later.
I've been doing some research into CVS and it looks like there are two approaches to doing the re-org:
1. Use the usual cvs add/remove/commit commands to move everything around. This would work, but it would be pretty tedious and we'd sort of lose the CVS histories.
2. Download the nightly CVS tarball to my machine, reorganize it, then upload it to SourceForge and have the SF admins install it as the new CVS tree. The one issue with this approach is that it would effect all CVS branches. A benefit would be the ability to _really_ remove the old, empty directories.
I prefer option 2.
My first step would be to wrap-up version 5.0.2 (bug fix release) and get that out of the way.
That would leave the embedded-* branches. Do those of you working on those branches have any concerns?
Below is the latest proposal for the new tree layout. Comments?
-Brian
------------------------------------------------------------------------
Mesa/ docs/ - documentation
include/ GL/ - OpenGL public headers gl.h glext.h glx.h glxext.h glu.h ...
src/ glu/ sgi/ - SGI GLU code (C++) mesa/ - old Mesa GLU code (C) mini/ - subset GLU for embedded
glut/ glx/ - GLUT based on GLX beos/ - GLUT for BeOS dos/ - GLUT for DOS ggi/ - GLUT for GGI
There's a miniglut as well, fwiw.
widgets/ - SGI widget code
mesa/ glapi/ glapi*.[ch] - dispatcher files APIspec file gl*.py - Python API scripts main/ - core Mesa sources attrib.c context.c enable.c ... CPU detection code transform/ - was tnl t_*.[ch] X86/3Dnow code transform_dd/ - TCL templates for drivers t_dd_*.[ch]
Call this driver_templates, maybe?
math/ - math/vector routines
m_*.[ch]
swrast/ - s/w rasterization
s_*.[ch]
mmx_blend.S
swsetup/ - was swrast_setup
ss_*.[ch]
arraycache/ - vertex array stuff
ac_*.[ch]
drivers/
common/ - reusable driver code
X11/ - X11 (XMesa) driver
osmesa/ - OSMesa drier
swfbdev/ - software fbdev driver
radeon/ - DRI/fbdev driver
radeon-es/ - subset radeon fbdev driver
r200/ ...
mga/ - DRI/fbdev driver
windows/
beos/
ggi/
glide/ - was FX driver
dos/
One thing that is a bit confusing is that some drivers are just drivers, wheras others are combinations of drivers and window system interfaces. It would be nice to have just drivers here and move the various window system binding codes to another directory.
This way you'd get to see a lot of similarity between the framebuffer-type drivers and it might be possible to abstract them down to not much, using either templates from common/ or a new module like the one Phil proposed.
So, anyway, the new proposal would be something like
libGL/
X11 - standalone X11 libGL
miniglx - standalone fbdev window system
dri - libGL that understands XFree86 DRI
amiga -
dos -etc.
In most cases you'd want to still compile the driver into the libGL object statically, but it would be nice to get these two pretty disjoint pieces of code separated out.
Also, the glapi code is really libGL code, isn't it? It might move in with this lot...
miniglx/ - MiniGLX libGL.so dri/ - es dri code
kernel/ - kernel drivers, modules agpgart-2.5/ drm/ radeon/ radeonfb/ radeonfb-2.5/
The substructure here needs some attention, understandably.
I would guess we'd mimic the DRI tree to some extent:
kerenl/
drm/
shared/
linux/
bsd/
fbdev/ - this is a maybeagpgart/ - this is a maybe-not
The last two are contentious as they have maintainers elsewhere, but fbdev in particular has been sketchy so I needed to keep my own copy in the embedded branch.
miniglx/ - subset GLX API
progs/ xdemos/ - Xlib / GLX demos demos/ - existing Mesa demos redbook/ - OpenGL redbook programs samples/ - SGI sample progs test/ - tests, omitted from tarball images/ - sample images for demos BeOS/ - old BeOS demos ggi/ - GGI progs windml/ - WindML progs util/ - utility functions, etc.
lib/ - compiled libraries
bin/ - shell scripts, etc.
------------------------------------------------------- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
