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 Build Process for Users.
13 ========================
15 If you only want to build a snapshot or a fresh CVS checkout of the
16 sources, you should go into the `mono' sibling directory and issue the
19 ./autogen --prefix=/usr/local
22 That will build and install the code in a single pass. The
23 compilation is bundled with the build due to depedencies on the class
24 libraries on the runtime.
26 Build Features for Developers.
27 ==============================
29 These instructions apply to both Linux and Windows. To build this
30 package, you must already have a C# compiler installed. This means
31 that to build on Linux, you need to get a distribution of the MCS
32 binaries; these are called monocharges. See README.building for
33 information on where to get them. On Windows, you can just use the
34 Microsoft compiler. You also need GNU make to build the software (on
35 Windows, you will need for example the Cygwin environment setup).
37 To build the compiler and class libraries, run:
41 The libraries will be placed in the directory class/lib/ and the mcs
42 compiler executable in mcs/.
44 To install them, run the following:
48 The default prefix is /usr/local. To change this configuration option type:
50 echo prefix=/your-prefix >> build/config.make
52 If you get "corlib out of sync" errors, try
56 The difference between the two modes is explained farther down.
61 If you are tracking Mono's development, you may sometimes need to share
62 the compiled libraries with others, you can do:
66 Or a light version, which contains only the essential libraries and
67 results in a much smaller file:
74 If you want to change the configuration options for the build process,
75 place your configuration options in build/config.make
77 A list of variables that control the build are listed in the file
78 build/config-default.make.
81 ======================
83 Don't worry about them too much. If you're wondering which to use:
84 use the default if you can (that's why it's the default!) and use
85 the atomic if you have to.
87 The default profile uses the C# compiler and class libaries as they
88 are built. This lets you build MCS without needing to have already
89 installed it, but can fail if the libraries change significantly.
90 (This is the source of the dreaded "corlib out of sync" warning, most
93 The atomic profile tries to use the system compiler and preexisting
94 MCS libraries. New libaries are built against this constant reference
95 point, so if a newly built library has a binary incompatibility, the
96 rest of your build can proceed.
98 If you want to always use the atomic profile, run this command:
100 echo PROFILE=atomic >> build/config.make
102 More About the Build System
103 ===========================
105 More information is found in build/README.*. Here's a quick rundown
108 * Unified build system for Windows and Linux. Windows is still
109 fairly untested, but "should work." Unfortunately I don't
110 have a Windows machine to test on, but Gonzalo can get
111 corlib to build I think and that's about as complicated as
114 * Profile support. 'make PROFILE=profilename' or 'export
115 PROFILE=profilename ; make' will work. Profiles are defined
116 in build/profiles/profilename.make ; right now there isn't
117 too much going on. The 'bootstrap' profile will build the
118 way makefile.gnu did on Linux, by setting MONO_PATH and
119 using mcs/mcs.exe; the default profile will build against
120 the existing system libraries and compile with 'mcs', which
121 should reduce a lot of 'corlib out of sync' warnings.
123 * Important variables are shared among makefiles now; you can
124 edit build/config.make (see build/config-default.make for a
125 template) and give global settings, or just have a much
126 saner time of writing new makefiles.
128 * Response files, stamps, and other build trivia now all land
129 in build/deps/, making the library build directories
132 * Test libraries now live in class/Library/Library_test.dll,
133 not class/Library/Test. 'make test' will build the test DLL,
134 'make run-test' will actually run the nunit tests. Set the
135 variable TEST_HARNESS to run with a program other than
136 nunit-console (for example, nunit-gtk).
138 * Standardized recursive targets: all, clean, install, test,
139 run-test. Read build/README.makefiles for definitions of
142 * (Relatively) sane 'make dist' target; 'make distcheck'
143 support; cute 'make monocharge' and 'make monocharge-lite'
144 targets. They're made possible because 'make install' now
145 supports DESTDIR a la automake, which I'm sure someone cares