Integrate a bit of the old FAQ in the modern doc, and reword Models.rst

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

diff --git a/doc/doxygen/inside_tests.doc b/doc/doxygen/inside_tests.doc
index c70b0b6..8f0f5ed 100644 (file)
--- a/doc/doxygen/inside_tests.doc
+++ b/doc/doxygen/inside_tests.doc
@@ -30,13 +30,13 @@ cmake. These tests are run for every commit and the result is publicly
 
 @verbatim
 ctest                     # Launch all tests
-ctest -R msg              # Launch only the tests which name match the string "msg"
+ctest -R mc-              # Launch only the tests which name match the string "mc-"
 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.
+ctest -R mc- -j5 --output-on-failure # You changed the model checker and want to check that you didn't break anything, huh?
+                                     # That's fine, I do so all the time myself.
 @endverbatim
 
 @section inside_tests_rununit Running the unit tests
@@ -102,13 +102,13 @@ To add a new integration test, you thus have 3 things to do:
  - <b>Add your test in the cmake infrastructure</b>. For that, modify
    the following file:
    @verbatim
-   <project/directory>/teshsuite/<interface eg msg>/CMakeLists.txt
+   <project/directory>/teshsuite/<interface eg s4u>/CMakeLists.txt
    @endverbatim
    Make sure to pick a wise name for your test. It is often useful to
    check a category of tests together. The only way to do so in ctest
    is to use the -R argument that specifies a regular expression that
-   the test names must match. For example, you can run all MSG test
-   with "ctest -R msg". That explains the importance of the test
+   the test names must match. For example, you can run all MC test
+   with "ctest -R mc-". That explains the importance of the test
    names.
 
 Once the name is chosen, create a new test by adding a line similar to
@@ -180,21 +180,21 @@ Just for the record, the slaves were created from the available
 template with the following commands:
 @verbatim
 #debian/ubuntu
-apt-get install gcc g++ gfortran automake cmake libboost-dev openjdk-8-jdk openjdk-8-jre libxslt-dev libxml2-dev libevent-dev libunwind-dev libdw-dev htop git python3 xsltproc libboost-context-dev
+apt-get install gcc g++ gfortran automake cmake libboost-dev libxslt-dev libxml2-dev libevent-dev libunwind-dev libdw-dev htop git python3 xsltproc libboost-context-dev
 #for dynamicanalysis:
-apt-get install jacoco libjacoco-java libns3-dev pcregrep gcovr ant sloccount
+apt-get install libns3-dev pcregrep gcovr sloccount
 
 #fedora
-dnf install libboost-devel openjdk-8-jdk openjdk-8-jre libxslt-devel libxml2-devel xsltproc git python3 libdw-devel libevent-devel libunwind-devel htop
+dnf install libboost-devel libxslt-devel libxml2-devel xsltproc git python3 libdw-devel libevent-devel libunwind-devel htop
 
 #netbsd
-pkg_add cmake gcc7 boost boost-headers automake openjdk8 libxslt libxml2 libunwind git htop python36
+pkg_add cmake gcc7 boost boost-headers automake libxslt libxml2 libunwind git htop python36
 
 #opensuse
-zypper install cmake automake clang boost-devel java-1_8_0-openjdk-devel libxslt-devel libxml2-devel xsltproc git python3 libdw-devel libevent-devel libunwind-devel htop binutils ggc7-fortran
+zypper install cmake automake clang boost-devel libxslt-devel libxml2-devel xsltproc git python3 libdw-devel libevent-devel libunwind-devel htop binutils ggc7-fortran
 
 #freebsd
-pkg install boost-libs cmake openjdk8 automake libxslt libxml2 libunwind git htop python3  automake gcc6 flang elfutils libevent
+pkg install boost-libs cmake automake libxslt libxml2 libunwind git htop python3  automake gcc6 flang elfutils libevent
 #+ clang-devel from ports
 
 #osx