4 The Mono project has developed mono, a CLI runtime. The build process
5 of each of these depends on nothing more than a C compiler and glib2.
7 However, to provide a working runtime environment, these programs must
8 be supplemented by the class libraries, which are written in C#. This
9 package contains the components written in C#: class libraries,
12 *********************************************************************
16 * Unless you are developing the class libraries, you should *
17 * not need to do any build steps in this directory. *
19 * Go to ../mono and read the README file to compile and *
22 *********************************************************************
24 If you only want to build a snapshot or a fresh CVS checkout of the
25 sources, you should go into the `mono' sibling directory and issue the
26 make fullbuild command, like this:
29 ./autogen.sh --prefix=/usr/local
32 That will build and install the code in a single pass. The
33 compilation is bundled with the build due to dependencies on the class
34 libraries on the runtime.
36 Build Features for Developers of Mono.
37 ======================================
39 These instructions apply to both Linux and Windows. To build this
40 package, you must already have a C# compiler installed. This means
41 that to build on Linux, you need to get a distribution of the MCS
42 binaries; these are called monocharges. They can be found at
43 www.go-mono.com/daily. On Windows, you can just use the
44 Microsoft compiler. You also need GNU make to build the software (on
45 Windows, you will need for example the Cygwin environment setup).
47 You can customize your MCS configuration by using:
49 ./configure [--prefix=PREFIX] [--profile=PROFILE]
51 If you do not run the above, the defaults are /usr/local for the
52 prefix, and `default' for the profile.
54 To build the compiler and class libraries, run:
58 The libraries will be placed in the directory class/lib/ and the mcs
59 compiler executable in mcs/.
61 To install them, run the following:
65 If you get "corlib out of sync" errors, try
69 The difference between the two modes is explained farther down.
74 Occasionally, something in the compiler or runtime changes enough that
75 an existing installation cannot complete a full build from cvs. In this case,
76 go to http://go-mono.com/daily and download a monocharge or monolite tarball.
77 Unpack and copy the .dlls to $prefix/lib and .exes to $prefix/bin/. Then
78 you should be able to complete the build normally (i.e. using make fullbuild).
80 wget http://go-mono.com/daily/monolite-20031028.tar.gz
81 tar -zxvf monolite-20031028.tar.gz
83 cp *.exe /usr/local/bin/.
84 cp *.dll /usr/local/lib/.
89 If you are tracking Mono's development, you may sometimes need to share
90 the compiled libraries with others, you can do:
94 Or a light version, which contains only the essential libraries and
95 results in a much smaller file:
102 If you want to change the configuration options for the build process,
103 place your configuration options in build/config.make
105 A list of variables that control the build are listed in the file
106 build/config-default.make.
108 Build profiles? What?
109 ======================
111 Don't worry about them too much. If you're wondering which to use:
112 use the default if you can (that's why it's the default!) and use
113 the atomic if you have to.
115 The default profile uses the C# compiler and class libaries as they
116 are built. This lets you build MCS without needing to have already
117 installed it, but can fail if the libraries change significantly.
118 (This is the source of the dreaded "corlib out of sync" warning, most
121 The atomic profile tries to use the system compiler and preexisting
122 MCS libraries. New libaries are built against this constant reference
123 point, so if a newly built library has a binary incompatibility, the
124 rest of your build can proceed.
126 If you want to always use the atomic profile, run this command:
128 ./configure --profile=atomic
130 More About the Build System
131 ===========================
133 More information is found in build/README.*. Here's a quick rundown
136 * Unified build system for Windows and Linux. Windows is still
137 fairly untested, but "should work." Unfortunately I don't
138 have a Windows machine to test on, but Gonzalo can get
139 corlib to build I think and that's about as complicated as
142 * Profile support. 'make PROFILE=profilename' or 'export
143 PROFILE=profilename ; make' will work. Profiles are defined
144 in build/profiles/profilename.make ; right now there isn't
145 too much going on. The 'bootstrap' profile will build the
146 way makefile.gnu did on Linux, by setting MONO_PATH and
147 using mcs/mcs.exe; the default profile will build against
148 the existing system libraries and compile with 'mcs', which
149 should reduce a lot of 'corlib out of sync' warnings.
151 * Important variables are shared among makefiles now; you can
152 edit build/config.make (see build/config-default.make for a
153 template) and give global settings, or just have a much
154 saner time of writing new makefiles.
156 * Response files, stamps, and other build trivia now all land
157 in build/deps/, making the library build directories
160 * Test libraries now live in class/Library/Library_test.dll,
161 not class/Library/Test. 'make test' will build the test DLL,
162 'make run-test' will actually run the nunit tests. Set the
163 variable TEST_HARNESS to run with a program other than
164 nunit-console (for example, nunit-gtk).
166 * Standardized recursive targets: all, clean, install, test,
167 run-test. Read build/README.makefiles for definitions of
170 * (Relatively) sane 'make dist' target; 'make distcheck'
171 support; cute 'make monocharge' and 'make monocharge-lite'
172 targets. They're made possible because 'make install' now
173 supports DESTDIR a la automake, which I'm sure someone cares