/
INSTALL.txt
179 lines (134 loc) · 6.65 KB
/
INSTALL.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
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.