Development: Getting Started
From MonoDevelop
It's relatively easy to get started working on MonoDevelop, but this page aims to make it easier to get off the ground.
| Table of contents |
Setting up an Environment
MonoDevelop doesn't require the very latest version of Mono, and we specifically depend on GTK+ features no later that GTK+ 2.8. That said, using a recent release of Mono and GTK# is likely to improve reliability and performance.
It is strongly recommended to use a packaged release of Mono for your distribution, as it is very easy to mix up conflicting Mono versions if installing from source. If you must install Mono from source, set up a Parallel Mono Environment (http://www.mono-project.com/Parallel_Mono_Environments).
Make sure you have Subversion installed, and check MonoDevelop out from Subversion.
Building and Installing
Open a terminal in the top-level MonoDevelop directory, and run
./configure --profile=core
It may fail because of missing dependencies; install them, and re-run the command.
There are a number of other profiles that can be used; the command
./configure --help
explains how they are used.
Next, use
make
to build MonoDevelop.
Since you're working on the development version, it's best not to install it; instead, you can use
make run
to run it without installing it.
It is a good idea to keep separate copies for using and developing.
If you do install MonoDevelop, it is best to run the current version uninstalled, to make sure it works, before installing it.
Working on MonoDevelop
Before hacking on MonoDevelop, don't be afraid to ask questions on #monodevelop IRC (http://mono-project.com/IRC) or MonoDevelop mailing list (http://lists.ximian.com/mailman/listinfo/monodevelop-list). People will be able to give you pointer about where to start and how best to approach the problems your are trying to solve. There are also number of Articles on the MonoDevelop architecture and on implementing addins.
The MonoDevelop solution can be opened from MonoDevelop, and builds can be preformed form within MonoDevelop. Indeed, some parts of the build (such as Stetic code generation) must be performed within MD. However, the modified MonoDevelop must be run from a terminal with
make run
You should follow our contribution rules, for code style and licensing. Please add ChangeLog entries for all of your changes. There's one for each assembly.
After you have made your changes, produce a diff
svn diff ChangeLog changedfile1.cs changedfile2.cs > some_diff_file.diff
and attach your patch to an issue in http://bugzilla.novell.com or send it to the MonoDevelop mailing list (http://lists.ximian.com/mailman/listinfo/monodevelop-list).
Using Subversion
Subversion is a very powerful source control system used to track and store the history of the source code. This section provides a minimal set of the terminology and commands to get you started. Simply add --help to the end of any subversion command to get information about the options available. The Subversion book (http://svnbook.red-bean.com/) is also very useful.
TRUNK contains the current development main line; the latest version is called HEAD.
Your directory that you checked out from Subversion is called a working copy. Any changes you make will be kept in your own copy, and won't affect the repository unless they are committed. If you are reading this, you most likely won't be able to commit them, but will have to generate a path and send it to be reviewed and committed by a maintainer. Every time a commit is made, a new revision of the code is created.
Note that most of the following commands can be followed by a list of file and directories, separated by spaces; without such a list, they use the current directory.
To update the working copy to HEAD, use the command
svn update
To see the changes that have occurred since you last updated, without updating, use the command
svn log -r BASE:HEAD
The log command can also be used to review the log message history of any file.
To see the changed files in your own copy, use
svn status
to list the changed files, and
svn diff
to view the actual changes. The diff command can also be used to view the changes between any two revisions.
New files can be tracked by adding them with
svn add
Changed files can be reverted back to their pristine version with
svn revert
Troubleshooting the Build
If the MonoDevelop build fails, there are a number of possible fixes.
If the build commands failed, try a clean rebuild:
make clean; make
Also, view the changed files:
svn info
and fix any that are in conflict, or delete any that have changed unnecessarily.
If the build system failed, check for changed files and re-run the configure script.
Powered by MediaWiki