[Mono-devel-list] moving things after the migration
Willibald Krenn
Willibald.Krenn at gmx.at
Mon Nov 22 12:11:43 EST 2004
Zoltan Varga schrieb:
> Hi all,
>
> Now that the SVN migration is complete, we could consider renaming/moving
> directories in our source tree.
This was a long standing whish of me. I talked about that with Miguel
months ago. Response was more or less 'No way'.. (Cause CVS couldn't
handle that)
Now I've set up my own local darcs (I love to experiment :-) ) tree with
a directory layout that fits my needs. I hope your directory changes
aren't too intrusive, 'cause that would blow my scripts totally.
Just to give you an idea of what I currently have:
- Utils (Global utilities and tools)
| - OriginalMono
| - Utils
| + Header
| + Source
| + MiniAmd64 (custom tools)
- Kernel (Contains Runtime, Metadata)
| - OriginalMono
| + AdditionalHeader
| + Arch
| + Cil
| - IO-Layer
| | + Header
| | + Source
| - Metadata (contains libruntime AND libmetadata?!)
| | + Header
| | + Source
| + Os
- GarbageCollector (The GarbageCollector module(s))
| - OriginalMono
| + Source (module 'libgc')
- Compiler (The JIT Compiler)
| - OriginalMono (module 'mini')
| | + Header
| | + Source
| + MiniAmd64 (custom AMD64 backend)
| + MonoBurg (the monoburg program)
| + CopyEmitDataCompiler (custom)
- Profiler (The Profiler module)
| + OriginalMono (?)
| + RAPGO (custom to MiniAMD64)
- Header (Symlinks(!) to public headers and config.h)
| + arch
| + cil
| + gc
| + ...
- Tests (Global Tests)
| + Compiler
+ Binary (Build directory tree; _ALL_ .o, .a and
| other build-generated files go here)
+ Scripts (Contains the SCons build scripts)
+ _darcs (Version Control System)
Ok, what's the idea behind that module organization? Simplify concurrent
development and ease the compilation of different Mono configurations:
e.g.: If someone was to implement a new GC, the module would go into
"GarbageCollector/MovingGC/(Header,Source,UnitTests)" and after altering
the symlinks in 'Header' and tweaking the build Script in
'GarbageCollector', it would be easy to build 'normal' mono with the new GC.
BTW: I really like SCons for doing the build part..
Regarding the mini module, I would probably seperate tests, header,
source, genmsdec or do something like
mini
- Arch
| - amd64
| | + ExceptionHandling
| | + Codegen
| | + Header
| + x86
| + ...
+ Cil2Tree (AFAIK this will become legacy)
+ DebugSupport
+ Optimizations
+ Tests
+ Tools
+ Documents
Back to lurking mode
Willi
More information about the Mono-devel-list
mailing list