Build reorganization

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.

_______________________________________________
Monodevelop-list mailing list
Monodevelop-listlists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

Build reorganization

Thread: Build reorganization