[MonoDevelop] Build reorganization
Charlie Poole
charlie at nunit.com
Tue Oct 23 20:44:14 EDT 2007
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
>
More information about the Monodevelop-list
mailing list