[MonoDevelop] Build reorganization

[Michael Hutchinson]

On 10/23/07, Lluis Sanchez <lluis at ximian.com> wrote:
> Hi!
>
> Now that we are approaching the 1.0 release it would be good to
> reorganize a bit our build system to make it more flexible and better
> fit our release plans.
>
> My idea is to remove some of the add-ins from the main MD build, and
> move them to a new "Extras" directory. Each add-in there would have its
> own configuration script and build files, and we would publish an
> independent tarball and package for each of them.
>
> Which kind of add-ins would be moved to Extras?
>
>       * Add-ins which are not used by most of people and that have
>         uncommon dependencies.
>       * Add-ins which are not stable enough for a 1.0 release, and which
>         we may want to ship independently.
>       * Add-ins which are not arch-independent (we don't have them right
>         now, but maybe in the future).
>
> The idea is to keep a Core MD build, with a limited and controlled
> number of dependencies, fully managed and stable. On the other hand keep
> a directory with add-ins with rare dependencies, or which are under
> development.

IMO we should move to a three level system -- Core, Main and Extras.
Core would contain the addins that are used as dependencies -- so they
need to have a stable API, assembly versioning, API documentation
and.pc files.

Main would be for addins that are supported/stable, and don't have
unusual dependencies.

Extras would be as you describe.

> I think this setup is more convenient than what we have now to make MD
> grow after the 1.0 release. The current way of adding new add-ins, which
> involves changing the main configuration script to add add-in specific
> checks and a new configuration flag for enabling/disabling the add-in is
> anything but flexible and scalable.

Agreed. However, it does have one nice advantage -- "make run", which
is incredibly useful while working on MD. It may be hard to duplicate
this properly with a fragmented build.

> Following this idea, the Core MD build might include:
>
>       * MonoDevelop.Core
>       * MonoDevelop.Core.Gui
>       * MonoDevelop.Projects
>       * MonoDevelop.Projects.Gui
>       * MonoDevelop.Ide
>       * MonoDevelop.Deployment
>       * MonoDevelop.Autotools
>       * MonoDevelop.DesignerSupport
+ NRefactory

And in Main:
>       * AspNetAddIn
>       * CBinding
>       * ChangeLogAddIn
>       * CSharpBinding
>       * VBNetBinding
>       * ILAsmBinding
>       * VersionControl
>       * WelcomePage
>       * MonoDevelop.Gettext
>       * MonoDevelop.GtkCore
>       * MonoDevelop.RegexToolkit
>       * MonoDevelop.SourceEditor
>       * MonoDevelop.WebReferences
>       * NUnit
>       * MonoDeveloperExtensions
>       * prj2make-sharp-lib
 * MonoDevelop.Database

> And we would move to the new Extras directory:
>
>       * AspNetEdit
>       * BooBinding
>       * GtkSharpLibs
>       * JavaBinding
>       * NemerleBinding
>       * PythonBinding
* MonoDevelop.Database database and designer addins

> I still don't know what's the best way of implement this new build
> system, but in any case, this split should not make MD more difficult to
> build or package.

or develop :)

> Ideas are welcome!
>
> Here is mine:
>
> In the MD SVN module create this directory structure:
>
> /MonoDevelop
>     Main
>         Core (current src/Core)
>         Addins (core add-ins listed above)

Well, I should have read this bit more carefully before re-proposing a
three-level system :-) That said, I still suggest we move some stuff
into Core. Dependency tracking within the build is bound to be a
problem -- one thing I'd like to have is for addins to depend upon the
dlls of their references, so that we don't get broken builds due to
API changes.

>     Extras
>         all other add-ins
>
> Move the current main config script and makefile to Main. Create a new
> config script and makefiles for each add-in in Extras.

Okay, makes sense. The Extras need to have a configurable MD location
to build against so that they can be integrated cleanly into the main
build.

They should also have a command to build an mpack file and install it
into the user's .config directory.

I propose we have a bunch of helper scripts and M4 macros (see
banshee's macros for an example).

There may also be problems with opening the MD solution with Extras
addins in it. It would be nice to have a local .pc file directory
within the build directory, so that the Extras addins could have their
own solutions that would be opened independently, while referencing
the locally built dlls rather than the installed/system dlls.

>
> Create a new global config script and makefile. This script would take
> as parameter a build profile name, which would also be the name of a
> file containing a list of 'packages' to build. For example a 'core'
> profile would contain only Main. A 'dist' profile would contain Main and
> all add-ins in Extras we usually publish. An 'all' profile would include
> everything.

Sounds good. We could put the profiles in a "profiles" dir. There
should also be a command to publish a set of mpacks to a repository.

>
> After configuring the build, 'make' would build all directories included
> in the profile, 'make dist' would create a tarball for each of those
> directories, and so on.
>
> This setup may not be very common. I don't know how other applications
> based on add-ins do it, so feedback is welcome.

Anything addin-based is bound to have problems integrating with distro
package management. It would be really cool if we could generate and
install RPMs and DEBs directly, both for MD core and for the extras.

-- 
Michael Hutchinson
http://mjhutchinson.com