[MonoDevelop] More detailed build response

[Todd Berman]

I have taken the post, and pasted it in here, and will attempt to
address potential issues inline. I will just use // for my own
questions, etc

There are most likely other issues, but there where some of the ones I
saw with a first readthrough.

--Todd


              MonoDevelop: Software Building Architecture 
                  Miguel de Icaza (miguel@ximian.com) 
This document is the result of various discussions with Mono and
MonoDevelop users on their needs to build, package and distribute their
software by using Mono Develop. 

I will update this as the discussion evolves on the mailing list. 


Considerations
Not all software projects handled by MonoDevelop are equal, there is a
range of options that must be taken into consideration: 

      * Web Services. 
      * Web Applications (.aspx/.ashx). 
      * ECMA Console and GUI applications. 
      * C libraries (typically glue). 
      * Compilation of different languages. 
      * Execution-specific environments. 

In addition to the above, certain applications must probe for specific
features on the target system where the software is to be deployed (C
libraries most of the time) or conditionally use one or more assemblies
at build time. Only a minority of applications will require this. 

//I assume by this you also mean probing for required assemblies.
//This is something we should add some automation for. For example, if
//I add gtksourceview-sharp as a reference to my project, the build
//system needs to be smart enough to add this to my build requirements
//
//What are we going to be doing to support existing auto* build
//systems. Will there be an easy way to run make on a certain
//directory?

We want applications to be self contained, so running an application
within MonoDevelop will not cause a full make/make install process to be
triggered before it can be executed. 

//Will this be accomplished with something similar to the build/
//directory in MD, or will we be doing something different?
//
//Also, how will items such as xml files, or images that need to be
//in a specific location be handled? I know below you address this
//partially with the ability to embed, but not all applications
//will want to use this functionality. And both should be supported

Instead, applications should run from any directory being invoked, and
should pull any data files that they require using relative paths to the
executable path. Most of the time this is not an issue, since data files
can be embedded into the executable as resource files (images, icons,
glade, xml resources are common ones). 

This is necessary so when a user runs an application in MonoDevelop,
MonoDevelop only needs to trigger the compilation and running of the
program on its current path for it to be functional.


Output
The master file remains the "cbmx" Combine file. All the information is
kept there, and auxiliary files are only generated to allow people to
deploy applications without requiring MonoDevelop to be installed. 

//I think we should be adding a third file for this. Another thing
//to keep in mind with adding this info to the cmbx file is the
//ability to reuse projects.
//
//Projects themselves should be self contained and know how to build
//themselves, so that you can use them from multiple solutions.

The generated output from the new build system should be a hand
generated configure script that will probe system features and generate
Makefiles to compile, install and remove a piece of software. 

//I assume you mean that we can write one (huge) configure script
//that we package with MD and then copy into the solutions top
//level folder. If so, what are we planning on writing this in?
//Also, are we going to use standard configurelike switches, such
//as --prefix, --disable-xxxx, --enable-xxxx, etc.

//Will this configure script allow for complicated conditional
//switching? (ie, if this lib is present, build yyy, if not, check
//for this other library, and do zzz, and if nothing is there, error
//out with this info).

Autoconf and automake are to be avoided for the traditional C# targets,
as these systems are better suited for C and C++ development and have
their own sets of portability and dependency problems.

//What about when you need to use C, as many projects do (MD included)
//Will we attempt to rewrite auto* for them, or encourage the use of
//auto* seperately and add hooks?
//
//The ability to compile C is a must-have for this build system, as
//designing something that is unable to self host is not good.

Compilation
The build should be driven by make in all cases. The current
infrastructure should be modified to generate the makefiles for the
current project before each compilation, and two targets can provide all
the needed features: all builds the software, and run would run the
execution script for this program. 

//Why not allow for more targets? make dist seems reasonable, as does
//make test for running tests. Potentially allowing people to append
//content to the makefiles and add their own should be supported.

This means that instead of calling the compiler with a response file
that we have hand-crafted, we should produce the Makefile for it that
contains everything we need it to build. 

The response file can still be used internally by the Makefile to work
around possible command-size limitations in Unix, so something like:
all: program program: program.exe program.exe: make-response mcs
@response make-response: echo '/target:executable -warnaserror' >
response echo 'f1.cs f2.cs f3.cs' >> response echo 'f4.cs' >> response
run: program ./program  

//I assume there will be support for flagging files as 'dont build'?


Execution Scripts
Mono programs typically include a wrapper script to invoke them, like
this: 


	#!/bin/sh
	/usr/bin/mono /usr/bin/program.exe $*
	

In certain Linux systems it is possible to have the kernel invoke
program.exe directly, but this is a feature only available on certain
kernels, not necessarily available to users without root access, and it
is definitely not available on the other platforms that Mono supports. 

Compiled executables for Mono will contain the above shell script to
invoke the program. In addition, the shell script could be used to set
an LD_LIBRARY_PATH for glue/helper libraries.

//I assume there will be gui for all this, where will this gui be
//located?

//Also, projects (not solutions) might have LD_LIBRARY_PATH needs.
//This needs to be accounted for.

Probing System Features
Our runtime and class libraries can isolate us from many system specific
dependencies but there are still some features that we might want to
support conditionally. 

For the sake of having a binary that works on every platform out of the
box without recompilation, it is sometimes preferable to delay until
runtime conditional features like this. Although this might not always
be possible. 

There are two places where probing takes place: 

      * During development, from the IDE. 
      * At deployment time, possibly without the IDE. 

Today we should use pkg-config to do the heavy lifting in terms of
probing for existing libraries: a dialog box can be used to define a
library, dependencies and possible the conditional build definitions
that are needed. 

//Will we add support for libraries that this build system produces
//to automatically produce an up to date .pc file and install it?

Probing of low-level Unix features in a way that integrates with the IDE
has not been yet studied, but I feel that these must be done in a case-
by-case basis: Library probing, method probing, or maybe even adding a
hook to insert some shell scripts to do the work. 

The probing would be generated into a configure file and would update a
configuration file (ProjectConfig.cs for C# code, and ProjectConfig.h
for C code). The same files that MonoDevelop would maintain from the
IDE.

//What exactly is the point of this file? to basically provide
//#if ENABLE_XXXX support?


Web Building
During development, when the user requests to run a web page, or a web
service should probe for an available port, launch XSP on that port and
finally start a web browser pointing to that address. 

The only trick is catching when the web browser has been closed so we
can return MonoDevelop to the "development" mode and shut down the XSP
server. 

We could just plainly ignore this and just trigger the execution.


Java and Mono
We should add a profile for developing using Java targetting the CLI.
This would take care of creating the jar files from the referenced
assemblies, use the system javac compiler and invoke Mono with IKVM with
the proper arguments. 

This should bring into consideration the integration of existing JAR
files into the IDE, and call IKVMC to build DLL files out of the system
jar files.


Source Code Packaging
The generated makefiles should support a target to ship the source code,
a feature that should also be available from MonoDevelop's IDE. This
probably can be done as a the `dist' makefile targte.

//What about make distcheck, considering that unless we rewrite auto*
//for the bundled c code, people using auto* for c might want to at
//least allow that code to be make distcheck'd somehow
//
//Also, i assume this will output a proper .tar.gz will all the
//needed stuff.

Binary Packaging
Creation of an RPM spec file is a possibility, but RPMs are not portable
to every platform. Maybe a zip file, or a compressed tar file are
options. 

//personally, i think this is *completely* outside the scope of a 
//build system.
//potentially providing hooks for this would be more than enough
//as every packagers requirements are completely different, and
//9 times out of 10, people dont package the apps they develop
//beyond simple tarballs.

Since the packages should allow to be hosted on any prefix location like
MacOS applications, it might not be much of an issue.