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

[Ben Maurer]

On Thu, 2005-11-03 at 21:10 -0500, Jonathan Pryor wrote:
> 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.

The primary problem with this is the fact that its a url, you lose a bit
of stuff by doing it (like the ability to easily make atomic commits
without referencing the "real" build directory).

I'd suggest we do:

/
	build
	mono-core
	mono-data

Most people will check out /, which will give them a fully buildable
directory (in fact, there could be a master makefile in here or
something). If somebody really wants to save on disk space, they can
check out build and mono-core in a directory (much like one checks out
mono and mcs).

A few comments about the directory layout you choose:


>   - 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)

Other modules depend on s.drawing, it would either need to be moved into
mono-core or its own module. Also, SWF only needs to be build once while
libgdiplus needs to be build once per arch: since swf is more rapily
changing its a plus to have it in a xplatform module.


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

I think the plan gets a bit icky around here. Consider when we get to a
point where we support the vb compiler. Clearly, we will want to apply
the same policy we do to mcs: keep it stable. In effect, we will want to
have the "default" configuration pull a more stable branch of vb. At the
same time Atlas might be alive and jumping, we'll want to give people
new versions every month with lots of changes. So we'll have to pull vb
out or something.

The point is, in many ways we are looking at two kinds of splits: 1)
splits across logical lines 2) splits across maintenance policy lines.
We need to come up with a way that developers can see split 2 and users
see split 1.

I'd note that the split you are coming up with looks suspiciously like
our rpm split. The rpm splits already cover the logical splits the way
our users see them. In some ways, I'd like to leave the rpm split alone
(this has been debated since prehistoric times, the current setup is the
3rd or so iteration) and only change the way we build mono. All we'd
need is some sort of control file that says "for the stable build, get
mono, mcs from branches/stable, and winforms from trunk" or something.

-- Ben