[MonoDevelop] Build reorganization
marcosmarin at gmail.com
Tue Oct 23 16:19:05 EDT 2007
On 10/23/07, Lluis Sanchez <lluis at ximian.com> wrote:
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.
Is a change to NAnt under consideration? NAnt supposedly makes crossplatform
building cleaner and easier, and I know making MonoDevelop crossplatform is
not in the current plans, but since one of the great things Mono has is
crossplatform development I think everyone is expecting MonoDevelop to be
multiplatform eventually. Since you are making big changes in the build
process, it might be worth considering changing to NAnt even if a
multiplatform MonoDevelop is not planned for the next 2-3 years.
Just my 2 cents.
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
> 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:
> Core (current src/Core)
> Addins (core add-ins listed above)
> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Monodevelop-list