[MonoDevelop] Build reorganization

Lluis Sanchez lluis at ximian.com
Tue Oct 23 12:37:36 EDT 2007


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.

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.

Following this idea, the Core MD build might include:

      * MonoDevelop.Core
      * MonoDevelop.Core.Gui
      * MonoDevelop.Projects
      * MonoDevelop.Projects.Gui
      * MonoDevelop.Ide
      * AspNetAddIn 
      * CBinding 
      * ChangeLogAddIn 
      * CSharpBinding 
      * MonoDevelop.Deployment 
      * MonoDevelop.Autotools 
      * MonoDevelop.DesignerSupport 
      * MonoDeveloperExtensions 
      * MonoDevelop.Gettext 
      * MonoDevelop.GtkCore 
      * MonoDevelop.RegexToolkit 
      * MonoDevelop.SourceEditor 
      * MonoDevelop.WebReferences 
      * NUnit 
      * prj2make-sharp-lib 
      * VBNetBinding 
      * ILAsmBinding 
      * VersionControl 
      * WelcomePage

And we would move to the new Extras directory:

      * AspNetEdit 
      * BooBinding 
      * GtkSharpLibs 
      * JavaBinding 
      * MonoDevelop.Database 
      * NemerleBinding 
      * PythonBinding


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. 

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

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.

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. 

Thanks!
Lluis.




More information about the Monodevelop-list mailing list