Basic Installation
==================
-The Mono project has developed mono, an x86-specific CL JIT compiler and
-mint, a portable CLI interpreter. The build process of each of these
-depends on nothing more than a C compiler, glib2 and libgc.
+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 corlib, a CLR assembly to which they are closely
-tied. This package provides the C# sources for corlib as well as some
-additional assemblies and mcs, the Mono C# compiler.
+be supplemented by the class libraries, which are written in C#. This
+package contains the components written in C#: class libraries,
+compilers and tools.
-To build this package, you must already have a C# compiler installed.
-Build instructions for *NIX and Microsoft Windows follow.
+Build Process for Users.
+========================
-Building mcs on *NIX
-====================
+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
+following command:
-mcs provides a set of makefiles which make it easy to build and install
-mcs on *NIX systems like Linux or FreeBSD where mcs is already
-installed.
+ ./autogen --prefix=/usr/local
+ make fullbuild
+
+That will build and install the code in a single pass. The
+compilation is bundled with the build due to depedencies on the class
+libraries on the runtime.
+
+Build Features for Developers.
+==============================
+
+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. See README.building for
+information on where to get them. 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).
To build the compiler and class libraries, run:
- make -f makefile.gnu
+ make
The libraries will be placed in the directory class/lib/ and the mcs
compiler executable in mcs/.
-To install them, run the following, where prefix identifies where you
-want the files installed:
+To install them, run the following:
+
+ make install
+
+The default prefix is /usr/local. To change this configuration option type:
+
+ echo prefix=/your-prefix >> build/config.make
- make -f makefile.gnu install prefix=/usr/local
+If you get "corlib out of sync" errors, try
+
+ make PROFILE="atomic"
+
+The difference between the two modes is explained farther down.
+
+Monocharges
+===========
If you are tracking Mono's development, you may sometimes need to share
-the compiled libraries with others. If you want to produce an easily
-distributable tarball, run:
+the compiled libraries with others, you can do:
- make -f makefile.gnu dist
+ make monocharge
-Building mcs on Windows
-=======================
+Or a light version, which contains only the essential libraries and
+results in a much smaller file:
-It is also possible to build mcs on Windows using the Microsoft .NET
-framework. This may be convenient if you do not have access to a working
-mcs setup. To build the compiler and class libraries, run:
+ make monocharge-lite
- make
+Configuration
+=============
-The libraries will be placed in the directory class/lib/ and the mcs
-compiler executable in mcs/. They can then be copied to /usr/lib and
-/usr/bin or wherever desired on the target system.
+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:
+
+ echo PROFILE=atomic >> build/config.make
+
+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.
projects / mono.git / blobdiff