Brian Paul wrote:
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.
ok.
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?
Or, how about moving this into drivers/common/ ?
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
In the cases where the API and driver are tightly integrated (X11 Mesa, OSMesa, DOS, Windows, etc.) I'd rather just keep things basically as-is (in the driver directory).
But when the API and drivers are really distinct, I agree to having separate directories.
miniglx - standalone fbdev window system
dri - libGL that understands XFree86 DRI
I was planning on the XF86/DRI libGL staying in the XFree86/DRI trees and not duplicated here.
amiga -
dos -
In light of the above, we're basically just left with miniglx. I have that as src/miniglx/. I'm not sure we need src/libGL/miniglx/. If we were to add the real GLX/DRI code, I think src/glx/ would suffice.
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 maybe
agpgart/ - 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.
I don't have a strong preference here. I just basically copied what's presently in the embedded-2 branch. I'll go with what you've suggested.
-Brian
------------------------------------------------------- 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
