Keith Whitwell wrote:
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.
How about a mixed approach: Open a branch with the existing CVS to prototype the new structure, do all the add/remove/commit stuff there until you have a working tree, then do (2) as a final irreversable step.
Like I said, doing all the changes by add/remove/commit would take a while. If I mess-up, I can always have the original tarball'd CVS tree restored.
I think we know how most of the re-org should go. If we get some bits like kernel/ wrong we can always do a second iteration.
[...]
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?
Actually, there's a lot of overlap between this and the drivers/common directory -- maybe just move all this code to there?
That was my idea too- move the transform_dd code into drivers/common/.
-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
