[MonoDevelop] Build reorganization

[Marcos Marín]

On 10/23/07, Lluis Sanchez <lluis at ximian.com> wrote:
>
> Hi!


Hello :-)

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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/monodevelop-list/attachments/20071023/7b73c1e0/attachment-0001.html