[simgrid.git] / doc / doxygen / install.doc

/*!
@page install Installing Simgrid

@tableofcontents

The easiest way to install SimGrid is to go for a binary package.
Under Debian or Ubuntu, this is very easy as SimGrid is directly
integrated to the official repositories.  If you just want to use
Java, simply copy the jar file on your disk and you're set. Note that
under Windows, you should go for Java, as the native C interface is
not supported on that OS.

Recompiling an official archive is not much more complex, actually.
SimGrid has very few dependencies and rely only on very standard
tools.  First, download the *@SimGridRelease.tar.gz* archive
from [the download page](https://gforge.inria.fr/frs/?group_id=12).
Then, recompiling the archive should be done in a few lines:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.sh}
tar xf @SimGridRelease.tar.gz
cd @SimGridRelease
cmake -DCMAKE_INSTALL_PREFIX=/opt/simgrid .
make
make install
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If you want to stay on the bleeding edge, you should get the latest
git version, and recompile it as you would do for an official archive.
Depending on the files you change in the source tree, some extra
tools may be needed.

@section install_binary Installing a binary package

@subsection install_binary_linux Binary packages for linux

Most of the developers use a Debian or Ubuntu system, and some of us
happen to be Debian Maintainers, so the packages for these systems are
well integrated with these systems and very up-to-date. To install them,
simply type:

@verbatim
apt-get install simgrid
@endverbatim

On other Linux variants, you probably want to go for a source install.
Please contact us if you want to contribute the build scripts for your
preferred distribution.

@subsection install_binary_java Using the binary jar file

The easiest way to install the Java bindings of SimGrid is to grab the
jar file from the
<a href="https://gforge.inria.fr/frs/?group_id=12">Download page</a>,
and copy it in your classpath (typically, in the same directory than
your source code). If you go for that version, there is no need to
install the C library as it is bundled within the jar file. Actually,
only a bunch of architectures are supported this way to keep the
jar file size under control and because we don't have access to every
exotic architectures ourselves.

If the jarfile fails on you, complaining that your architecture is not
supported, drop us an email: we may extend the jarfile for you, if we
have access to your architecture to build SimGrid on it.

If the error message is about the boost-context library, then you
should install that library on your machine. This is a known issue in
the 3.12 release that will be fixed in the next release.

You can retrieve a nightly build of the jar file from our autobuilders. 
For Windows, head to 
<a href="https://ci.appveyor.com/project/mquinson/simgrid">AppVeyor</a>.
Click on the artefact link on the right, and grab your file. If the
latest build failed, there will be no artefact so you will need to
first click on "History" on the top to search for the last successful
build.
For non-Windows systems (Linux, Mac or FreeBSD), head to 
<a href="https://ci.inria.fr/simgrid/job/SimGrid-Multi">Jenkins</a>.
In the build history, pick the last green (or at least yellow) build
that is not blinking (ie, that is done building). In the list, pick a
system that is close to your system, and click on the ball in the
Debug row. The build artefact appear on the top of the resulting page.

@section install_src Installing from source

@subsection install_src_deps Resolving the dependencies

SimGrid only uses very standard tools:
  - C compiler, C++ compiler, make and friends.
  - perl (but you may try to go without it)
  - We use cmake to configure our compilation
      (<a href="http://www.cmake.org/cmake/resources/software.html">download page</a>).
      You need cmake version 2.8.8 or higher. You may want to use ccmake
      for a graphical interface over cmake.
  - LibBoost:
    - osX: with <a href="http://www.finkproject.org/">fink</a>: `sudo fink install boost1.53.nopython`
    - debian: `apt-get install libboost-dev libboost-context-dev`

On MacOSX, it is advised to use the clang compiler (version 3.0 or
higher), from either MacPort or XCode.  See also @ref install_cmake_mac.

Building from the source on Windows, may be something of an adventure.
We never managed to compile SimGrid with something else than MinGW-64
ourselves. We usually use the
<a href="http://www.activestate.com/activeperl/downloads">activestate</a>
version of Perl, and the
<a href="http://msysgit.googlecode.com/files/Git-1.7.4-preview20110204.exe">msys</a>
version of git on this architecture, but YMMV. You can have a look at
the configuration scripts in the appveyor.yml file, but you are
basically on your own here. Sorry. We are not fluent with Windows so
we cannot really help. 

@subsection install_src_fetch Retrieving the source

If you just want to use SimGrid, you should probably grab the latest
stable version available from the
<a href="https://gforge.inria.fr/frs/?group_id=12">download page</a>.
We do our best to release soon and release often, but sometimes you
need to install the developer version of SimGrid, directly from the
git repository. Avoid the git version if you are not sure, as it may
break on you, or even worse.

@verbatim
git clone git://scm.gforge.inria.fr/simgrid/simgrid.git simgrid
@endverbatim

@subsection install_src_config Configuring the build

Note that compile-time options are very different from @ref options
"run-time options".

\subsubsection install_cmake_howto Setting compilation options

The default configuration should be ok for most usages, but if you
need to change something, there is several ways to do so. First, you
can use environment variables. For example, you can change the used
compilers by issuing these commands before launching cmake:

@verbatim
export CC=gcc-4.7
export CXX=g++-4.7
@endverbatim

Note that other variables are available, such as CFLAGS and CXXFLAGS to add
options for respectively the C compiler and the C++ compiler.

Another way to do so is to use the -D argument of cmake as follows.
Note that the terminating dot is mandatory (see @ref
install_cmake_outsrc to understand its meaning).

@verbatim
cmake -DCC=clang -DCXX=clang++ .
@endverbatim

Finally, you can use a graphical interface such as ccmake to change
these settings. Simply follow the instructions after starting the
interface.

@verbatim
ccmake .
@endverbatim

\subsubsection install_cmake_list SimGrid compilation options

In addition to the classical cmake configuration variables, SimGrid
accepts several options, as listed below.

  @li <b>CMAKE_INSTALL_PREFIX</b> (path): Where to install SimGrid
      (e.g. /usr/local or /opt).

  @li <b>enable_compile_optimizations</b> (ON/OFF): request the
      compiler to produce efficient code. You want to activate it,
      unless you want to debug SimGrid itself (as efficient code may
      be appear mangled to the debuggers).

  @li <b>enable_debug</b> (ON/OFF): disable this if simulation speed
      really matters to you. All log messages of gravity debug or
      below will be discarded at compilation time. Since there is
      quite a bunch of such log messages in SimGrid itself, this can
      reveal faster than discarding them at runtime as usually. But of
      course, it is then impossible to get any debug message from
      SimGrid if something goes wrong.

  @li <b>enable_model-checking</b> (ON/OFF): Only enable this if you
      actually plan to use the model-checking aspect of SimGrid. This
      mode of execution is still under heavy work, but it should be
      rather usable now. Be <b>warned</b> that this option will hinder
      your simulation speed even if you simulate without activating
      the model-checker. We are working on improving this situation.

  @li <b>enable_compile_warnings</b> (ON/OFF): request the compiler to
      issue error message whenever the source code is not perfectly
      clean. If you develop SimGrid itself, you must activate it to
      ensure the code quality, but as a user, that option will only
      bring you issues.

  @li <b>enable_maintainer_mode</b> (ON/OFF): you only need to set
      this option if you modify very specific parts of SimGrid itself
      (the XML parsers and other related elements). Adds an extra
      dependency on flex and flexml.

  @li <b>enable_tracing</b> (ON/OFF): disable this if you have issues
      with the tracing module. But this module is now very stable and
      you really should try to enjoy this beauty.

  @li <b>enable_smpi</b> (ON/OFF): disable this if you have issues
      with the module allowing to run MPI code on top of SimGrid. This
      module very stable, but if you really don't need it, you can
      disable it.

  @li <b>enable_mallocators</b> (ON/OFF): disable this when tracking
      memory issues within SimGrid, or the caching mechanism used
      internally will fool the debuggers.

  @li <b>enable_jedule</b> (ON/OFF): enable this to get SimDag
      producing traces that can then be visualized with the Jedule
      external tool.

  @li <b>enable_lua</b> (ON/OFF): enable this if you want to enjoy the
      lua bindings of SimGrid. Adds an extra dependency on lua library
      and developer header files.


  @li <b>enable_ns3</b> (ON/OFF): whether you want to use ns3.
      See section @ref pls_simgrid_configuration_ns3.
  @li <b>NS3_HINT</b> (path): Where to search for NS3 (eg /usr or /opt).
  @li <b>enable_latency_bound_tracking</b> (ON/OFF): enable it if you
      want to be warned when communications are limited by round trip
      time while doing packet-level simulation.
  @li <b>enable_documentation</b> (ON/OFF) : whether the documentation should be
       generated during the compilation. Default is ON.

\subsubsection install_cmake_reset Resetting the compilation configuration

If you need to empty the cache of values saved by cmake (either
because you added a new library or because something seriously went
wrong), you can simply delete the file CMakeCache.txt that is created
at the root of the source tree. You may also want to edit this file
directly in some circumstances.

\subsubsection install_cmake_outsrc Compiling into a separate directory

By default, the files produced during the compilation are placed in
the source directory. As the compilation generates a lot of files, it
is advised to to put them all in a separate directory. It is then
easier to cleanup, and this allows to compile several configurations
out of the same source tree. For that, simply enter the directory
where you want the produced files to land, and invoke cmake (or
ccmake) with the full path to the SimGrid source as last argument.
This approach is called "compilation out of source tree".

@verbatim
mkdir build
cd build
cmake [options] ..
make
@endverbatim

\subsubsection install_cmake_mac Cmake on Mac OS X

SimGrid compiles like a charm with clang on Mac OS X:

@verbatim
cmake -DCMAKE_C_COMPILER=/path/to/clang -DCMAKE_CXX_COMPILER=/path/to/clang++ .
make
@endverbatim

With the XCode version of clang 4.1, you may get the following error message:
@verbatim
CMake Error: Parse error in cache file build_dir/CMakeCache.txt. Offending entry: /SDKs/MacOSX10.8.sdk
@endverbatim

In that case, edit the CMakeCache.txt file directly, so that the
CMAKE_OSX_SYSROOT is similar to the following. Don't worry about the
warning that the "-pthread" argument is not used, if it appears.
@verbatim
CMAKE_OSX_SYSROOT:PATH=/Applications/XCode.app/Contents/Developer/Platforms/MacOSX.platform/Developer
@endverbatim

\subsection install_src_compil Compiling SimGrid

In most cases, compiling and installing SimGrid is enough:

@verbatim
make
make install # try "sudo make install" if you don't have the permission to write
@endverbatim

In addition, several compilation targets are provided in SimGrid. If
your system is well configured, the full list of targets is available
for completion when using the Tab key. Note that some of the existing
targets are not really for public consumption so don't worry if some
stuff don't work for you.

@verbatim
make simgrid                    Build only the SimGrid library and not any example
make masterslave                Build only this example (and its dependencies)
make clean                      Clean the results of a previous compilation
make install                    Install the project (doc/ bin/ lib/ include/)
make uninstall                  Uninstall the project (doc/ bin/ lib/ include/)
make dist                       Build a distribution archive (tgz)
make distcheck                  Check the dist (make + make dist + tests on the distribution)
make doc                        Create SimGrid documentation
@endverbatim

If you want to see what is really happening, try adding VERBOSE=1 to
your compilation requests:

@verbatim
make VERBOSE=1
@endverbatim

@subsection install_src_test Testing SimGrid

Once everything is built, you may want to test the result. SimGrid
comes with an extensive set of regression tests (see @ref
inside_tests "that page of the insider manual" for more
details). Running the tests is done using the ctest binary that comes
with cmake. These tests are run for every commit and the result is
publicly <a href="https://ci.inria.fr/simgrid/">available</a>.

\verbatim
ctest                     # Launch all tests
ctest -R msg              # Launch only the tests which name match the string "msg"
ctest -j4                 # Launch all tests in parallel, at most 4 at the same time
ctest --verbose           # Display all details on what's going on
ctest --output-on-failure # Only get verbose for the tests that fail

ctest -R msg- -j5 --output-on-failure # You changed MSG and want to check that you didn't break anything, huh?
                                      # That's fine, I do so all the time myself.
\endverbatim

\section install_setting_own Setting up your own code

\subsection install_setting_MSG MSG code on Unix

Do not build your simulator by modifying the SimGrid examples.  Go
outside the SimGrid source tree and create your own working directory
(say <tt>/home/joe/SimGrid/MyFirstScheduler/</tt>).

Suppose your simulation has the following structure (remember it is
just an example to illustrate a possible way to compile everything;
feel free to organize it as you want).

\li <tt>sched.h</tt>: a description of the core of the
    scheduler (i.e. which functions are can be used by the
    agents). For example we could find the following functions
    (master, forwarder, slave).
\li <tt>sched.c</tt>: a C file including <tt>sched.h</tt> and
    implementing the core of the scheduler. Most of these
    functions use the MSG functions defined in section \ref
    msg_task_usage.
\li <tt>masterslave.c</tt>: a C file with the main function, i.e.
    the MSG initialization (MSG_init()), the platform
    creation (e.g. with MSG_create_environment()), the
    deployment phase (e.g. with MSG_function_register() and
    MSG_launch_application()) and the call to MSG_main()).

To compile such a program, we suggest to use the following
Makefile. It is a generic Makefile that we have used many times with
our students when we teach the C language.

\verbatim
all: masterslave
masterslave: masterslave.o sched.o

INSTALL_PATH = $$HOME
CC = gcc
PEDANTIC_PARANOID_FREAK =       -O0 -Wshadow -Wcast-align \
                                -Waggregate-return -Wmissing-prototypes -Wmissing-declarations \
                                -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations \
                                -Wmissing-noreturn -Wredundant-decls -Wnested-externs \
                                -Wpointer-arith -Wwrite-strings -finline-functions
REASONABLY_CAREFUL_DUDE =       -Wall
NO_PRAYER_FOR_THE_WICKED =      -w -O2
WARNINGS =                      $(REASONABLY_CAREFUL_DUDE)
CFLAGS = -g $(WARNINGS)

INCLUDES = -I$(INSTALL_PATH)/include
DEFS = -L$(INSTALL_PATH)/lib/
LDADD = -lm -lsimgrid
LIBS =

%: %.o
        $(CC) $(INCLUDES) $(DEFS) $(CFLAGS) $^ $(LIBS) $(LDADD) -o $@

%.o: %.c
        $(CC) $(INCLUDES) $(DEFS) $(CFLAGS) -c -o $@ $<

clean:
        rm -f $(BIN_FILES) *.o *~
.SUFFIXES:
.PHONY: clean

\endverbatim

The first two lines indicates what should be build when typing make
(<tt>masterslave</tt>) and of which files it is to be made of
(<tt>masterslave.o</tt> and <tt>sched.o</tt>). This makefile assumes
that you have set up correctly your <tt>LD_LIBRARY_PATH</tt> variable
(look, there is a <tt>LDADD = -lm -lsimgrid</tt>). If you prefer using
the static version, remove the <tt>-lsimgrid</tt> and add a
<tt>$(INSTALL_PATH)/lib/libsimgrid.a</tt> on the next line, right
after the <tt>LIBS = </tt>.

More generally, if you have never written a Makefile by yourself, type
in a terminal: <tt>info make</tt> and read the introduction. The
previous example should be enough for a first try but you may want to
perform some more complex compilations...


*/