[MonoDevelop] Build reorganization

[Lluis Sanchez]

El dl 29 de 10 del 2007 a les 15:28 -0400, en/na Michael Hutchinson va
escriure:
> 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.

I think we can still easily support it.

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

The problem with that is that you may end much many assemblies than
needed, even when it's not necessary.

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

I rather prefer using simple makefiles not based on autotools.

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

or we can just use assembly references.

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