#
# Copyright (c) 2017-2018 The SimGrid Team. Licence: LGPL of WDFPL, as you want.
+if [ ! -e Makefile ] ; then
+ echo "Please configure SimGrid before building it:"
+ echo " ccmake ."
+ exit 1
+fi
+
(
(nice make -j4 || make) && nice ctest -j4 --output-on-failure ; date
) 2>&1 | tee BuildSimGrid.sh.log
+++ /dev/null
-This page summarizes how to compile SimGrid. The full Install
-documentation is available in doc/html/install.html or online at
-
- http://simgrid.gforge.inria.fr/
-
-Getting the Dependencies
-------------------------
-SimGrid only uses very standard tools:
- - C compiler, C++ compiler, make and friends.
- - perl (but you may try to go without it)
- - cmake (version 2.8.8 or higher). You may want to use ccmake for a graphical interface over cmake.
- - boost:
- - Max OS X: with fink: fink install boost1.53.nopython, or with homebrew: brew install boost
- - Debian / Ubuntu: apt-get install libboost-dev libboost-context-dev
- - Java (if you want to build the Java bindings):
- - Mac OS X or Windows: Grab a full JDK
- - Debian / Ubuntu: apt-get install default-jdk
-
-Build Configuration
--------------------
-Note that compile-time options are very different from run-time options.
-
-The default configuration should be fine for most usages, but if you
-need to change something, there are several ways to do so. First, you
-can use environment variables. For example, you can change the
-compilers used by issuing these commands before launching cmake:
-
- export CC=gcc-4.7
- export CXX=g++-4.7
-
-Note that other variables are available, such as CFLAGS and CXXFLAGS
-to add options respectively for the C and C++ compilers.
-
-Another way to do so is to use the -D argument of cmake as follows. Note that the ending dot is mandatory (see Out of Tree Compilation).
-
- cmake -DCC=clang -DCXX=clang++ .
-
-Finally, you can use the ccmake graphical interface to change these settings.
-
- ccmake .
-
-Existing compilation options
-----------------------------
-
- CMAKE_INSTALL_PREFIX (path)
- Where to install SimGrid (/opt/simgrid, /usr/local, or elsewhere).
- enable_compile_optimizations (ON/OFF)
- Request the compiler to produce efficient code. You want to
- activate it, unless you plan to debug SimGrid itself. Indeed,
- efficient code may be appear mangled to debuggers.
- enable_compile_warnings (ON/OFF)
- Request the compiler to issue error messages whenever the source
- code is not perfectly clean. If you are a SimGrid developer, you
- have to activate this option to enforce the code quality. As a
- regular user, this option will bring you nothing.
- enable_debug (ON/OFF)
- Disable this option toto discard all log messages of gravity debug
- or below at compile time. The resulting code is faster than if you
- discarding these messages at runtime. However, it obviously becomes
- impossible to get any debug info from SimGrid if something goes
- wrong.
- enable_documentation (ON/OFF)
- Generate the documentation pages.
- enable_java (ON/OFF)
- To enjoy the java bindings of SimGrid.
- enable_jedule (ON/OFF)
- To get SimDag producing execution traces that can then be
- visualized with the Jedule external tool.
- enable_lua (ON/OFF)
- To enjoy the lua bindings to the SimGrid internals.
- enable_lib_in_jar (ON/OFF)
- Bundle the native java bindings in the jar file.
- enable_lto (ON/OFF)
- Enable the Link Time Optimization of the C compiler. This feature
- really speeds up the produced code, but it is fragile with some
- versions of GCC.
- enable_maintainer_mode (ON/OFF)
- Only needed if you plan to modify very specific parts of SimGrid
- (e.g., the XML parsers and other related elements). Moreover, this
- adds an extra dependency on flex and flexml.
- enable_mallocators (ON/OFF)
- Disabled this when tracking memory issues within SimGrid, or our
- internal memory caching mechanism will fool the debuggers.
- enable_model-checking (ON/OFF)
- This execution gear is very usable now, but enabling this option at
- compile time will hinder simulation speed even when the
- model-checker is not activated at run time.
- enable_ns3 (ON/OFF)
- Allow to use ns-3 as a SimGrid network model.
- enable_smpi (ON/OFF)
- Allow to run MPI code on top of SimGrid.
- enable_smpi_ISP_testsuite (ON/OFF)
- Add many extra tests for the model-checker module.
- enable_smpi_MPICH3_testsuite (ON/OFF)
- Add many extra tests for the MPI module.
-
-Reset the build configuration
------------------------------
-
-To empty the cmake cache (either when you add a new library or when
-things go seriously wrong), simply delete your CMakeCache.txt. You may
-also want to directly edit this file in some circumstances.
-
-Out of Tree Compilation
------------------------
-
-By default, the files produced during the compilation are placed in
-the source directory. It is however often better to put them all in a
-separate directory: cleaning the tree becomes as easy as removing this
-directory, and you can have several such directories to test several
-parameter sets or architectures. For that, go to the directory where
-the files should be produced, and invoke cmake (or ccmake) with the
-full path to the SimGrid source as last argument.
-
- mkdir build
- cd build
- cmake [options] ..
- make
-
-Mac OS X Builds
----------------
-SimGrid compiles like a charm with clang (version 3.0 or higher) on Mac OS X:
-
- cmake -DCMAKE_C_COMPILER=/path/to/clang -DCMAKE_CXX_COMPILER=/path/to/clang++ .
- make
-
-With the XCode version of clang 4.1, you may get the following error message:
-CMake Error: Parse error in cache file build_dir/CMakeCache.txt. Offending entry: /SDKs/MacOSX10.8.sdk
-
-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.
-CMAKE_OSX_SYSROOT:PATH=/Applications/XCode.app/Contents/Developer/Platforms/MacOSX.platform/Developer
-
-In the El Capitan version of Max OS X, Apple decided that users don't
-need no /usr/include directory anymore. If you are hit by this pure
-madness, just run the following command to restore that classical UNIX
-directory: xcode-select -install
-
-Windows Builds
---------------
-
-Building SimGrid on Windows may be something of an adventure: We only
-manage to do so ourselves with MinGW-64, ActiveState Perl and msys
-git). Have a look at out configuration scripts in appveyor.yml, but
-don't expect too much from us: we are really not fluent with Windows.
-Actually your help is welcome.
-
-The drawback of MinGW-64 is that the produced DLL are not compatible
-with MS Visual C. clang-cl sounds promising to fix this. If you get
-something working, please tell us.
-
-Build the Java bindings
------------------------
-
-Once you have the full JDK installed (on Debian/Ubuntu, grab the
-package default-jdk for that), things should be as simple as:
-
- cmake -Denable_java=ON .
- make
-
-After the compilation, the file simgrid.jar is produced in the root
-directory. If you only want to build the jarfile and its dependencies,
-type make simgrid-java_jar. It will save you the time of building
-every C examples and other things that you don't need for Java.
-
-Sometimes, the build system fails to find the JNI headers:
- Error: jni could not be found.
-
-In this case, you need to first locate them as follows:
- $ locate jni.h
- /usr/lib/jvm/java-7-openjdk-amd64/include/jni.h
- /usr/lib/jvm/java-8-openjdk-amd64/include/jni.h
-
-Then, set the JAVA_INCLUDE_PATH environment variable to the right
-path, and relaunch cmake. If you have several version of jni installed
-(as above), use the right one (check the java version you use with
-javac -version).
-
- export JAVA_INCLUDE_PATH=/usr/lib/jvm/java-8-openjdk-amd64/include/
- cmake -Denable_java=ON .
- make
-
-Note that the filename jni.h was removed from the path.
-
-32 bits Builds on Multi-arch Linux
-----------------------------------
-
-On a multiarch x86_64 Linux, it should be possible to compile a 32 bit version of SimGrid with something like:
-CFLAGS=-m32 \
-CXXFLAGS=-m32 \
-PKG_CONFIG_LIBDIR=/usr/lib/i386-linux-gnu/pkgconfig/ \
-cmake . \
--DCMAKE_SYSTEM_PROCESSOR=i386 \
--DCMAKE_Fortran_COMPILER=/some/path/to/i686-linux-gnu-gfortran \
--DGFORTRAN_EXE=/some/path/to/i686-linux-gnu-gfortran \
--DCMAKE_Fortran_FLAGS=-m32
-If needed, implement i686-linux-gnu-gfortran as a script:
-#!/usr/bin/env sh
-exec gfortran -m32 "$@"
-
-Existing Compilation Targets
-----------------------------
-In most cases, compiling and installing SimGrid is enough:
- make
- make install # try "sudo make install" if you don't have the permission to write
-
-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 doesn't work for you.
-
-make simgrid Build only the SimGrid library and not any example
-make app-masterworker Build only this example (works for any example)
-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 documentation Create SimGrid documentation
-
-If you want to see what is really happening, try adding VERBOSE=1 to your compilation requests:
-
- make VERBOSE=1
-
-Testing your build
-------------------
-
-Once everything is built, you may want to test the result. SimGrid
-comes with an extensive set of regression tests (as described in the
-insider manual). The tests are run with ctest, that comes with CMake.
-We run them every commit and the results are on our Jenkins.
-
-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.
+++ /dev/null
-Using Git for SimGrid
-=====================
-
-SimGrid developement tree is now managed with Git.
-So, you need to use Git to:
-
-- follow the last development of SimGrid;
-- propose some new commit to SimGrid developpers.
-
-
-Installing Git and finding documentation
-----------------------------------------
-Refer to your OS documentation for installing Git.
-
-On Debian/Unbuntu, you can install the following packages:
- apt-get install git-core git-gui gitk git-email
-
-Git website is http://git.or.cz/ . A **lot** of documentation is available on
-this website. You can read for example the
-link:http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html[Tutorial
-Introduction to Git] to begin with Git.
-
-
-Setting up GIT on your computer
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Be sure that git will use your right name and email for commits:
-
- git config --global user.name "Firstname Lastname"
- git config --global user.email Firstname.Lastname@example.com
-
-Note: the "--global" switch ensure that these setups will be used for all
-git projects. You can change these settings per project without this flags
-(see "git help config" for more information)
-
-
-Getting a working copy of SimGrid developement tree
-------------------------------------------------
-
-Read-only access:
- git clone git://scm.gforge.inria.fr/simgrid/simgrid.git
-
-Read-write access (for people with account on the forge and in the SimGrid
-project):
- git clone git+ssh://USER@scm.gforge.inria.fr/gitroot/simgrid/simgrid.git
-(replace USER by your login name on the forge)
-
-Note: due to the distributed nature of Git, it is probably better to checkout
-with a read-only access and later push in the official repo with another
-"remote" setup (see later).
-
-Creating a commit
-~~~~~~~~~~~~~~~~~
-A commit is a self-contained modification of the sources associated to
-meta-data such as author, date, message, etc.
-
-Several rules must be repected as much as possible:
-
-- all commits in public branches should lead to a state where "make"
- works (required in order git-bisect to be useful);
-- all commits in public branches must never be rebased (use "git revert" if you
- need to revert a public commit);
-- each commit should contain only one logical modification;
-- this modification must be described in the log message. The first line of the
- log is a summary, the second line should be empty, the next lines can
- describe more precisely the modifications.
-
-
-Your first line of commit message can begin with a [flag] telling which global
-part of SimGrid you are changing. It can be for example [doc], [network], [build
-system], [bugfix], etc.
-
-[bugfix] commits will probably be considered to be also applied in the last
-stable branch.
-
-If you need to modify your commits (changeset) before publishing them (better
-log message, splitting/merging of commits, ...), you can use:
-
-- "git gui" to modify (ammend) the last commit (check the good box);
-- "gitk" to cherry pick interresting commits (right-clic on interesting
- commits) and (re)create a linear branch;
-- "git rebase -i" to merge/split/reorder commits in a linear branch;
-- "git commit --amend" in the simple case;
-- your email or your feet to go ask for help ;-)
-
-
-Writing in the official repo
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-People with an account on the forge (and in the SimGrid group) are allowed
-to publish their changes in the main repo. However, they can only
-create/modify/remove heads under refs/heads/$forge_login/*
-
-Global branches $global such as 'master', 'stable-*', ... are only writable
-if they are a subset of a refs/heads/$forge_login/official/$global .
-Restrictions to push to these global branches can be added if required.
-
-To publish some commit, the easiest way is to create a "remote" config
-such as:
- git remote add inria-forge git+ssh://$forge_login@scm.gforge.inria.fr/gitroot/simgrid/simgrid.git
-
-And then, you should add to the configuration (in the [remote "inria-forge"]
-section of .git/config) some lines such as (replace $forge_login by your
-login on the forge):
- push = refs/heads/master:refs/heads/$forge_login/wip/master
- push = refs/heads/public/*:refs/heads/$forge_login/*
- push = +refs/heads/wip/*:refs/heads/$forge_login/wip/*
-The idea here is to establish a correspondance between local heads and remote
-heads. As said before, remote heads **must** match refs/heads/$forge_login/*
-in order the push to succeed.
-
-Note: you can also add the previous config directly into the [remote "origin"]
-section if your clone has been done with the ssh protocol.
-
-You can create one-to-one correspondances (lines 1) or global correspondances
-(lines 2 and 3) as you wish. If you add a '+' in front of the line (line 3),
-then non fast-forward updates will be allowed. See 'man git-push' for more
-information.
-
-You can them push your commits with:
- git push inria-forge
-
-
-To summary, with this setup:
-- local branch named master is pushed to '$forge_login/wip/master';
-- local branches named 'public/*' are pushed to '$forge_login/*';
-- local branches named 'wip/*' are pushed to '$forge_login/wip/*';
-- other local branches are not pushed.
-
-Putting something in the 'master', 'stable-*', ... branches
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Just create a branch that merge the current 'master', 'stable-*', ... branch
-(called $global in this text) you want to update, push it first as
-$forge_login/official/$global and then push it as $global.
- With the previous example setup, if you want to update 'master' to include
-your current commit, you have to type something like:
- git merge inria-forge/master
- git push inria-forge HEAD:$forge_login/official/master
- git push inria-forge HEAD:master
-You can also add some config in .git/config such as
- push = refs/heads/user-master:refs/heads/$forge_login/official/master
- push = refs/heads/global-master:refs/heads/master
-
- You can also ask one official maintainer of this branch to pull from your one
-(ie publish your branch and give its name to the official maintainers).
-
-Note: take care to ask to push only well commented, well formed changeset.
-Use 'git-rebase' to cleanup your branch if needed. Do not hesitate to ask for
-help if you do not know how to do it.
-
-Publishing branches
-~~~~~~~~~~~~~~~~~~~
-There is mainly two reasons for which you might want to publish some of your
-commits:
-
-- to merge your work into the main (master) developement branch. You must then
-ensure that the branch you want to publish is ready to be merged (well
-commented, well formed, bug free changeset) and then ask for a merge (see
-previous paragraph). If 'make' does not produce a working binary, you should
-reconsider seriously your request.
-
-Even if your work is not merged immediately, you should never rebase this
-branch (i.e. only fast-forward commits should be done). SimGrid developers
-should use public/* heads to track these kind of works;
-
-- to allow you/other people to test some experimental features. Rebase can
-occurs here, so other developers must never merge from theses branches unless
-they really know what they do. SimGrid developers should use wip/* heads to
-track these kind of works;
-
-To summary: commits in public/* heads (and 'master', 'stable-*' heads) must
-never be rebased as they can be used by other people. Take care before
-pushing such heads!
-
-Essential commands
-------------------
-
-You can probably do most of your work with the following commands:
-
-- git clone: get a new repo
-- git gui: commit some changes (graphical program)
- You can very easily modify your last commit with this program
-- gitk: look at commits and manage branches (graphical program)
-- git rebase: rewrite/reorganize your (not yet public) commits
-- git fetch: get upstream changes
-- git merge: merge commits present on other branches
-- git pull: do a fetch and a merge
-- git push: publish your changes
+[](http://makeapullrequest.com)
[](https://travis-ci.org/simgrid/simgrid)
[](https://ci.appveyor.com/project/mquinson/simgrid)
[](https://sonarcloud.io/dashboard/?id=simgrid)
+++ /dev/null
- ************************************************
- *** This file is a TODO. It is thus kinda ***
- *** outdated. You know the story, right? ***
- ************************************************
-
-###
-### Urgent stuff:
-###
-
-* Have a proper todo file
-
-###
-### Ongoing stuff
-###
-
-* Clean up CMake files
- Non exhaustive list of subgoals:
- - Use genuine cmake mechanisms and variables when available,
- instead of reinventing the wheel.
- - Correctly determine system and architecture (e.g. x32).
- - Correctly determine compiler type and version (e.g. clang).
- - Use git to generate the dist archive. Either use git-archive to
- generate the tarball, or keep using cmake -E tar, but use git-ls-files
- to get the list of files to pack.
-
-* Replace XBT with the C++ standard library
remains simple to use: most unpleasant technical elements can be
abstracted away rather easily.
+This page describes the C version of this API while the :ref:`Java
+bindings of MSG <Java_doc>` are described in another section.
+
.. warning::
MSG used to be the main API of SimGrid 3, but we are currently in
MPI profilers). You can reuse this mecanism for any kind of trace
that you want to replay, for example to study how a P2P DHT overlay
reacts to a given workload.
- - Simulating algorithms with one of the legacy interfaces: MSG and
- SimDAG (in C or Java). SimGrid was founded in 1998, and many
- interfaces were proposed along the way. MSG, introduced around
- 2002, is still present in SimGrid. It does not evolve anymore, but
- given its popularity, it will not be removed until at least 2020.
+ - Simulating algorithms with one of the legacy interfaces: :ref:`MSG
+ for distributed algorithms <MSG_doc>` (in :ref:`C <MSG_doc>` or
+ :ref:`Java <Java_doc>`) and SimDAG for
+ centralized algorithms (in C). SimGrid was founded in 1998, and
+ many interfaces were proposed along the way. MSG (introduced
+ around 2002) and SimDag (introduced before 2000), are still present
+ in SimGrid. They do not evolve anymore, but given their popularity,
+ they will not be removed until at least 2020. That being said, our
+ goal is to make S4U so useful that these legacy APIs become useless
+ and obsolete.
- We are currently working on the ability to modify any existing
application so that it can run on top of SimGrid. This project,
called `Remote-SimGrid
+ BuildSimGrid\.sh
+ COPYRIGHT\.template
-+ README\.(coding|git)
++ README\.coding
+ \.appveyor\.yml
+ \.circleci/.*
+ \.clang-format
