mcs/INSTALL.txt

   1 Basic Installation
   2 ==================
   3
   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.
   6
   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,
  10 compilers and tools.
  11
  12 Build Process for Users.
  13 ========================
  14
  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
  17 following command:
  18
  19           ./autogen --prefix=/usr/local
  20           make fullbuild
  21
  22 That will build and install the code in a single pass.  The
  23 compilation is bundled with the build due to dependencies on the class
  24 libraries on the runtime.
  25
  26 Build Features for Developers.
  27 ==============================
  28
  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. They can be found at
  33 www.go-mono.com/daily. 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).
  36
  37 To build the compiler and class libraries, run:
  38
  39     make
  40
  41 The libraries will be placed in the directory class/lib/ and the mcs
  42 compiler executable in mcs/.
  43
  44 To install them, run the following:
  45
  46     make install
  47
  48 The default prefix is /usr/local. To change this configuration option type:
  49
  50     echo prefix=/your-prefix >> build/config.make
  51
  52 If you get "corlib out of sync" errors, try
  53
  54     make PROFILE="atomic"
  55
  56 The difference between the two modes is explained farther down.
  57
  58 Troubleshooting
  59 ===============
  60
  61 Occasionally, something in the compiler or runtime changes enough that
  62 an existing installation cannot complete a full build from cvs.  In this case,
  63 go to http://go-mono.com/daily and download a monocharge or monolite tarball.
  64 Unpack and copy the .dlls to $prefix/lib and .exes to $prefix/bin/.  Then
  65 you should be able to complete the build normally (i.e. using make fullbuild).
  66
  67         wget http://go-mono.com/daily/monolite-20031028.tar.gz
  68         tar -zxvf monolite-20031028.tar.gz
  69         cd monolite-20031028
  70         cp *.exe /usr/local/bin/.
  71         cp *.dll /usr/local/lib/.
  72
  73 Monocharges
  74 ===========
  75
  76 If you are tracking Mono's development, you may sometimes need to share
  77 the compiled libraries with others, you can do:
  78
  79     make monocharge
  80
  81 Or a light version, which contains only the essential libraries and
  82 results in a much smaller file:
  83
  84     make monocharge-lite
  85
  86 Configuration
  87 =============
  88
  89 If you want to change the configuration options for the build process,
  90 place your configuration options in build/config.make
  91
  92 A list of variables that control the build are listed in the file
  93 build/config-default.make.
  94
  95 Build profiles? What?
  96 ======================
  97
  98 Don't worry about them too much. If you're wondering which to use:
  99 use the default if you can (that's why it's the default!) and use
 100 the atomic if you have to.
 101
 102 The default profile uses the C# compiler and class libaries as they
 103 are built. This lets you build MCS without needing to have already
 104 installed it, but can fail if the libraries change significantly.
 105 (This is the source of the dreaded "corlib out of sync" warning, most
 106 of the time.)
 107
 108 The atomic profile tries to use the system compiler and preexisting
 109 MCS libraries. New libaries are built against this constant reference
 110 point, so if a newly built library has a binary incompatibility, the
 111 rest of your build can proceed.
 112
 113 If you want to always use the atomic profile, run this command:
 114
 115         echo PROFILE=atomic >> build/config.make
 116
 117 More About the Build System
 118 ===========================
 119
 120 More information is found in build/README.*. Here's a quick rundown
 121 of the features:
 122
 123         * Unified build system for Windows and Linux. Windows is still
 124           fairly untested, but "should work." Unfortunately I don't
 125           have a Windows machine to test on, but Gonzalo can get
 126           corlib to build I think and that's about as complicated as
 127           it gets.
 128
 129         * Profile support. 'make PROFILE=profilename' or 'export
 130           PROFILE=profilename ; make' will work. Profiles are defined
 131           in build/profiles/profilename.make ; right now there isn't
 132           too much going on. The 'bootstrap' profile will build the
 133           way makefile.gnu did on Linux, by setting MONO_PATH and
 134           using mcs/mcs.exe; the default profile will build against
 135           the existing system libraries and compile with 'mcs', which
 136           should reduce a lot of 'corlib out of sync' warnings.
 137
 138         * Important variables are shared among makefiles now; you can
 139           edit build/config.make (see build/config-default.make for a
 140           template) and give global settings, or just have a much
 141           saner time of writing new makefiles.
 142
 143         * Response files, stamps, and other build trivia now all land
 144           in build/deps/, making the library build directories
 145           cleaner.
 146
 147         * Test libraries now live in class/Library/Library_test.dll,
 148           not class/Library/Test. 'make test' will build the test DLL,
 149           'make run-test' will actually run the nunit tests. Set the
 150           variable TEST_HARNESS to run with a program other than
 151           nunit-console (for example, nunit-gtk).
 152
 153         * Standardized recursive targets: all, clean, install, test,
 154           run-test.  Read build/README.makefiles for definitions of
 155           what they should do
 156
 157         * (Relatively) sane 'make dist' target; 'make distcheck'
 158           support; cute 'make monocharge' and 'make monocharge-lite'
 159           targets. They're made possible because 'make install' now
 160           supports DESTDIR a la automake, which I'm sure someone cares
 161           about.