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 depedencies 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. 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).
  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 Monocharges
  59 ===========
  60
  61 If you are tracking Mono's development, you may sometimes need to share
  62 the compiled libraries with others, you can do:
  63
  64     make monocharge
  65
  66 Or a light version, which contains only the essential libraries and
  67 results in a much smaller file:
  68
  69     make monocharge-lite
  70
  71 Configuration
  72 =============
  73
  74 If you want to change the configuration options for the build process,
  75 place your configuration options in build/config.make
  76
  77 A list of variables that control the build are listed in the file
  78 build/config-default.make.
  79
  80 Build profiles? What?
  81 ======================
  82
  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.
  86
  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
  91 of the time.)
  92
  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.
  97
  98 If you want to always use the atomic profile, run this command:
  99
 100         echo PROFILE=atomic >> build/config.make
 101
 102 More About the Build System
 103 ===========================
 104
 105 More information is found in build/README.*. Here's a quick rundown
 106 of the features:
 107
 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
 112           it gets.
 113
 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.
 122
 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.
 127
 128         * Response files, stamps, and other build trivia now all land
 129           in build/deps/, making the library build directories
 130           cleaner.
 131
 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).
 137
 138         * Standardized recursive targets: all, clean, install, test,
 139           run-test.  Read build/README.makefiles for definitions of
 140           what they should do
 141
 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
 146           about.