180 lines
6.7 KiB
Plaintext
180 lines
6.7 KiB
Plaintext
Basic Installation
|
|
==================
|
|
|
|
The Mono project has developed mono, a CLI runtime. The build process
|
|
of each of these depends on nothing more than a C compiler and glib2.
|
|
|
|
However, to provide a working runtime environment, these programs must
|
|
be supplemented by the class libraries, which are written in C#. This
|
|
package contains the components written in C#: class libraries,
|
|
compilers and tools.
|
|
|
|
*********************************************************************
|
|
* *
|
|
* NOTICE *
|
|
* *
|
|
* Unless you are developing the class libraries, you should *
|
|
* not need to do any build steps in this directory. *
|
|
* *
|
|
* Go to ../mono and read the README file to compile and *
|
|
* install. *
|
|
* *
|
|
* ../mono is where you have your `mono' source download *
|
|
* *
|
|
*********************************************************************
|
|
|
|
If you only want to build a snapshot or a fresh CVS checkout of the
|
|
sources, you should go into the `mono' sibling directory and issue the
|
|
make command, like this:
|
|
|
|
cd ../mono
|
|
./autogen.sh --prefix=/usr/local
|
|
make
|
|
make install
|
|
|
|
The compilation is bundled with the build due to dependencies on the
|
|
class libraries on the runtime.
|
|
|
|
Build Features for Developers of Mono.
|
|
======================================
|
|
|
|
These instructions apply to both Linux and Windows. To build this
|
|
package, you must already have a C# compiler installed. This means
|
|
that to build on Linux, you need to get a distribution of the MCS
|
|
binaries; these are called monocharges. They can be found at
|
|
www.go-mono.com/daily. On Windows, you can just use the
|
|
Microsoft compiler. You also need GNU make to build the software (on
|
|
Windows, you will need for example the Cygwin environment setup).
|
|
|
|
You can customize your MCS configuration by using:
|
|
|
|
./configure [--prefix=PREFIX] [--profile=PROFILE]
|
|
|
|
If you do not run the above, the defaults are /usr/local for the
|
|
prefix, and `default' for the profile.
|
|
|
|
To build the compiler and class libraries, run:
|
|
|
|
make
|
|
|
|
The libraries will be placed in the directory class/lib/ and the mcs
|
|
compiler executable in mcs/.
|
|
|
|
To install them, run the following:
|
|
|
|
make install
|
|
|
|
If you get "corlib out of sync" errors, try
|
|
|
|
make PROFILE="atomic"
|
|
|
|
A better alternative would be to fire off a 'make' from a sibling or
|
|
parent 'mono/' tree.
|
|
|
|
Troubleshooting
|
|
===============
|
|
|
|
We try to maintain the CVS tree such that it is bootstrapable from the
|
|
latest released version of mono and mcs. Occasionally, something in the
|
|
compiler or runtime changes enough that an existing installation cannot
|
|
complete a bootstrap from cvs. In this case, go to
|
|
http://go-mono.com/daily and download a monocharge or monolite tarball.
|
|
Unpack and copy the .dlls to $prefix/lib and .exes to $prefix/bin/.
|
|
Then you should be able to complete the build normally (i.e. using make
|
|
bootstrap).
|
|
|
|
wget http://go-mono.com/daily/monolite-20040505.tar.gz
|
|
tar -zxvf monolite-20040505.tar.gz
|
|
cd monolite-20040505
|
|
env prefix=/usr/local sh recharge.sh
|
|
|
|
Monocharges
|
|
===========
|
|
|
|
If you are tracking Mono's development, you may sometimes need to share
|
|
the compiled libraries with others, you can do:
|
|
|
|
make monocharge
|
|
|
|
Or a light version, which contains only the essential libraries and
|
|
results in a much smaller file:
|
|
|
|
make monocharge-lite
|
|
|
|
Configuration
|
|
=============
|
|
|
|
If you want to change the configuration options for the build process,
|
|
place your configuration options in build/config.make
|
|
|
|
A list of variables that control the build are listed in the file
|
|
build/config-default.make.
|
|
|
|
Build profiles? What?
|
|
======================
|
|
|
|
Don't worry about them too much. If you're wondering which to use:
|
|
use the default if you can (that's why it's the default!) and use
|
|
the atomic if you have to.
|
|
|
|
The default profile uses the C# compiler and class libaries as they
|
|
are built. This lets you build MCS without needing to have already
|
|
installed it, but can fail if the libraries change significantly.
|
|
(This is the source of the dreaded "corlib out of sync" warning, most
|
|
of the time.)
|
|
|
|
The atomic profile tries to use the system compiler and preexisting
|
|
MCS libraries. New libaries are built against this constant reference
|
|
point, so if a newly built library has a binary incompatibility, the
|
|
rest of your build can proceed.
|
|
|
|
If you want to always use the atomic profile, run this command:
|
|
|
|
./configure --profile=atomic
|
|
|
|
More About the Build System
|
|
===========================
|
|
|
|
More information is found in build/README.*. Here's a quick rundown
|
|
of the features:
|
|
|
|
* Unified build system for Windows and Linux. Windows is still
|
|
fairly untested, but "should work." Unfortunately I don't
|
|
have a Windows machine to test on, but Gonzalo can get
|
|
corlib to build I think and that's about as complicated as
|
|
it gets.
|
|
|
|
* Profile support. 'make PROFILE=profilename' or 'export
|
|
PROFILE=profilename ; make' will work. Profiles are defined
|
|
in build/profiles/profilename.make ; right now there isn't
|
|
too much going on. The 'bootstrap' profile will build the
|
|
way makefile.gnu did on Linux, by setting MONO_PATH and
|
|
using mcs/mcs.exe; the default profile will build against
|
|
the existing system libraries and compile with 'mcs', which
|
|
should reduce a lot of 'corlib out of sync' warnings.
|
|
|
|
* Important variables are shared among makefiles now; you can
|
|
edit build/config.make (see build/config-default.make for a
|
|
template) and give global settings, or just have a much
|
|
saner time of writing new makefiles.
|
|
|
|
* Response files, stamps, and other build trivia now all land
|
|
in build/deps/, making the library build directories
|
|
cleaner.
|
|
|
|
* Test libraries now live in class/Library/Library_test.dll,
|
|
not class/Library/Test. 'make test' will build the test DLL,
|
|
'make run-test' will actually run the nunit tests. Set the
|
|
variable TEST_HARNESS to run with a program other than
|
|
nunit-console (for example, nunit-gtk).
|
|
|
|
* Standardized recursive targets: all, clean, install, test,
|
|
run-test. Read build/README.makefiles for definitions of
|
|
what they should do
|
|
|
|
* (Relatively) sane 'make dist' target; 'make distcheck'
|
|
support; cute 'make monocharge' and 'make monocharge-lite'
|
|
targets. They're made possible because 'make install' now
|
|
supports DESTDIR a la automake, which I'm sure someone cares
|
|
about.
|