[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