[Mono-dev] Win32 Gtk# Installers (Was: Re: C bindings VS C++ bindings (Gtk# vs. Kimono?))

[Jerome Haltom]

> Sadly this is the case, but it's no different than how we operate
> currently with every installer (Medsphere, Mono, Pidgin, etc) bringing
> in their own version of Gtk+, Gtk# and friends.

> 
> It would be great if there was a better solution, but the main focus of
> merge modules *for Medsphere and Novell/Mono* is to share the
> maintenance responsibilities for developing installers.  If this whole
> thing works out, Medsphere will be maintaining a Gtk+ merge module, and
> Novell would maintain the Gtk# one.  Then, Novell and Medsphere will
> build their own installers that bring in the modules that they want
> without duplicating tons of effort.

I think there is a better answer. I believe if you have been working
hard on preparing merge modules, those modules can easily be converted
to full installer files. These can form the base of the official Gtk
distribution for Win32.

If we can agree on installation location for Gtk and it's dependencies,
versioning requirements, and perhaps having the Wix files in Gtk+
upstream, then these MSI files can be a dependency of future MSI files
generated for Gtk# and Mono.

This is a subject I'd really like to talk about. I had created some MSI
files for the Gtk stack which I never saw through to completion. During
that process I came across some ideas and best practices I thought would
really make them polished. Are you available on some sort of IRCish
medium or something?

> <snip>
> 
> > Microsoft recommends that you create a .msi file for each primary
> > distributable (Gtk, Gtk#, Mono, etc) and have the application
> > distributor build a bootstrapper which references these .msi files
> > independently. VS2005 has a setup project built in which does this: it
> > automatically generates a bootstrapper that installs .Net itself.
> 
> Interesting -- I'll look into this approach.
> 
> -Brad
>