[Mono-dev] To split or not to split Mono?

[Jonathan Pryor]

On Thu, 2005-11-03 at 15:49 -0500, Miguel de Icaza wrote:
>     By keeping all of Mono in a single package (runtime, compilers, core
> libraries, GUI libraries, web libraries, database libraries and
> "others") it is making our future maintenance of code more difficult.
...
>     So am wondering whether we should split mcs/class into various
> packages that can be released independently.  This would minimize the
> branch maintenance pain and means that when we fix a bug in
> Windows.Forms we do not have to re-issue the whole Mono stack.

I'm all for a module split-up.

>     I had initially proposed "GUI", "Server", "Database" and "Core", but
> this is not necessarily a good split.  Database code for example
> requires Windows.Forms to be around.   So maybe we need a different
> split.
> 
>     Am not sure if we will split Mono, but if we do, I have already
> chosen the names for the modules: Red, Green, Blue and Yellow.

For the love of $DEITY, please don't use Red, Green, Blue, and Yellow.
These are not intuitive at all, and would cause more confusion than
clarity.  (Is there any clarity in those names?)

I'm all for splitting things up.  Coming up with a sensible split-up is
somewhat more difficult.  I'm not particularly fond of GUI, Server,
Database, and Core, primarily because I don't know what should be in
Server.  GUI, Database, and Core sound good.

Alternatively, it might be useful to make a (clearer) distinction
between the .NET-compatible "stack" and the ECMA stacks.  This isn't
entirely possible given how the ECMA stack has many .NET improvements,
but it might be something to keep in mind.

Regardless, a split that removes circular dependencies should be used
(hence the implied proposal below to merge mono & mcs into mono-core).

The breakup I'd suggest is this:

  - mono-core (the `mono' module renamed)
    - tools
      - mcs (mcs/mcs moved here)
      - ... (mcs/tools/* moved here)
    - assembly
      - mscorlib (rename corlib!)
      - System
      - System.Runtime.Remoting
      - System.Runtime.Serialization
      - System.Xml
      - ... (anything that's truly *core* and/or needed for ECMA, etc.)
    - ... (the rest of the current `mono' module)

  - mono-data (DB-related functionality)
    - assembly
      - System.Data
      - System.Data.OracleClient
      - Mono.Data
      - ...

  - mono-winforms (GUI support)
    - assembly
      - System.Drawing
      - System.Windows.Forms (from mcs/class/Managed.Windows.Forms)
    - libgdiplus (instead of a separate module, since these are tied)

  - mono-aspnet (ASP.NET)
    - assembly
      - System.Web
      - System.Web.Services
    - xsp (move the xsp module here)

  - mono-utils (Utility libraries)
    - assembly
      - Mono.Posix (renamed to Mono.Unix? :-)
      - PEAPI
      - Mono.C5
      - Mono.GetOptions

  - mono-mscompat (non-core Microsoft-compatibility assemblies)
    - assembly
      - System.Transactions
      - Microsoft.* (Build, VisualBasic, Web.Atlas, etc.)
    - tools
      - xbuild

I'm not sure this is the best breakup (as I don't know the entire
dependency tree), but I assume that something like this is possible,
where dependencies are organized in a reasonable manner (mono-winforms
depends on mono-core and mono-data, mono-data only depends on mono-core,
mono-utils depends on mono-core, etc.).

As for the build system, it would be nice if we could have a mono-build
module that was inserted into every checkout into a `build' directory
"as if" through CVS' ampersand modules.  This would allow a manner of
consistency across all modules without needing to manually update each
copy individually, resulting in incompatibilities.  svn has a similar
mechanism via the svn:externals property; see:

	http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-7-sect-3

I'm not sure how well svn:externals works in practice though.  In
particular the "feature" that svn:externals refers to a URL is rather
annoying, as it means we'd have to use a URL that anonymous users can
access, implying that we could only update the build system by updating
the mono-build module (and not via any of the existing checkouts).  It
also undermines the ability to have multiple anonymous svn repositories.
It's something to consider anyway.

 - Jon