[MonoDevelop] Autotool Deployment Addin

[Lluis Sanchez]

Hi Matze, the add-in looks awesome!
Some comments inline...

> Hi,
> 
> Attached to this mail is an AddIn for Autotool deployment of monodevelop
> projects. You basically right click on the assembly and monodevelop will
> create a configure.ac and a bunch of Makefile.am and wrapper scripts for
> your exe files. The thing works good enough that a project of mine with
> a few dozens .cs files spread over 7 projects in a solution can be
> successfully deployed and a "make install", "make dist" and "make
> distcheck" work nicely.
> 
> The main part of the Addin is a template engine which gets fed with
> information from the monodevelop projects. The Addin contains several
> template files for Makefile.am and configure.ac as resources. The plan
> is that the user can override these in his projects when he has special
> needs.
> 
> Things to be done:
>  - Deploy into a new directory and copy relevant files over instead of
> spreading the Makefile.ams around the project
>  - An option to let users override the templates that are used
>  - Some wizard or something that explains users on first export how to
> override templates, asks for missing info and maybe sets a default
> directory for deployment
>  - Automatically running autoreconf -i in the deployed directory
>  - An option to deploy and "make dist" in 1 go
> 
> There are some Problems for which I still have no solution:
>  - Where to get package name and package version from. For package name
> you can probably use the name of the solution, but a solution has no
> version. I could also use additional informations like a contact e-mail
> address.

See http://www.monodevelop.com/How_to_extend_the_Project_Model,
specially the section "Adding properties to existing project or solution
types". This is what you want to do. Add "Package name", "version",
"e-mail" and whatever you need to DotNetProject.

>  - Files in monodevelop projects have a fixed set of properties and
> buildactions. So currently it's not possible to do custom rules to
> handle .addin.xml files in a sensible manner for example. It would be
> nice to have a way to add custom attributes to files in a monodevelop
> project.

ProjectFile objects are not extensible, but Project objects are. You can
keep custom rule information there.

However, what MD currently lacks is its own deployment model. Rules like
copying files to the install directory should be part core deployment
model. The autotools add-in would just map those rules to makefile
rules.

I know that we can't cover everything that can be done in autotools in
our deployment model, but I think it's worth thinking a bit about it,
and take a decision about what we want to support natively in MD, and
what can only be implemented in an autotools extension.

>  - What should I do with the build  configurations? Currently I simply
> always use the Release configuration

Using the Release configuration should be OK for now.

At mid term, I think that the configuration information should also be
added to the generated configuration file. For example, if a project has
two configurations, debug and release, the generated configuration file
could be run using --enable-debug or --enable-release, and would set the
configuration options accordingly.

>  - I'm not sure how to support additional languages. Sure I could add
> rules for boo or nemerle. But that would mean I have to make the plugin
> dependent on the boo and nemerle plugin to gather the compiler flags,
> having this dependency is not a good idea since many people don't have
> these plugins installed.

MonoDevelop has a well defined (although poorly documented) extension
system. What you need to do is:

      * Create an interface to be implemented by any language add-in
        that wants to provide support for autotools. It would be
        something like ILanguageBinding, but instead of a Compile method
        you would get a GetCompileCommand method or something like that.
      * Implement a AbstractCodon subclass. You can take
        LanguageBindingCodon as an example. This is what add-ins will
        use to register their interface implementations.
      * In your add-in xml file, define an extension point using the
        "Extension" element.
      * In the autotools add-in, get all objects registered by add-ins
        using Runtime.AddInService.GetTreeItems ("your/extension/path").

I'll try to write detailed instructions in the wiki.

>  - How could I allow users to use custom templates for solution files
> (custom configure.ac template for example)

Same as before: you can add custom properties to the Combine type.

Lluis.