[MonoDevelop] Build reorganization

[Charlie Poole]

Any chance of your catching up with NUnit's recent releases
for the 1.0 release?

Charlie 

> -----Original Message-----
> From: monodevelop-list-bounces at lists.ximian.com 
> [mailto:monodevelop-list-bounces at lists.ximian.com] On Behalf 
> Of Lluis Sanchez
> Sent: Tuesday, October 23, 2007 9:38 AM
> To: monodevelop-list at lists.ximian.com
> Cc: Miguel de Icaza
> Subject: [MonoDevelop] 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-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-list
>