**
******************************************************
-There is at least 4 sub-projects in the tree:
+There is at least 5 sub-projects in the tree:
- XBT: eXtended Bundle of Tools (low-level toolbox: logging, datatypes).
- SURF: a SimUlation aRtiFact. This is the simulation kernel.
- MSG: originally MetaSimGrid, MSG is a simple distributed application
simulator.
- - SMPI: Simulated MPI, to run MPI application using emulation technics.
+ - SMPI: Simulated MPI, to run MPI application using emulation technics;
+ - MC: model-checker;
+ - SIMIX: basix interface for simulated processes. This layer defines simcalls
+ (simulation calls) exposed to the simulated processes by the SIMIX "kernel".
+ This interface is used to implement the MSG, SMPI layers.
+ - SIMDAG;
They are all in the same tree because they are complementary tools and
having all of them in the same package makes the installation easier
src/include -> another location for protected headers. Used by SURF, and
other should be converted, since this is the Right Thing.
- testsuite/ -> The more test the better.
- Same organization than src/ and include/
- Tests are allowed to load some headers of the module they test.
- All tests should be listed in run_test.in so that they get
- run on 'make check'.
-
examples/ -> Supposed to be copy/pastable by the user, so keep it clear and
avoid any kind of trick. In particular, do only include the
public headers here.
teshsuite/ -> The more test the better. Put in there any strange test
- doing things that the users are not supposed to do,
- just to see if our framework is robust to incorrect and
- unusual behaviors. All tests written in this section
- should leverage our tesh(1) utility.
-
- testsuite/ -> Old test suite, that should be converted to tesh and
- moved to teshsuite at some point.
+ doing things that the users are not supposed to do,
+ just to see if our framework is robust to incorrect and
+ unusual behaviors. All tests written in this section
+ should leverage our tesh(1) utility.
**
** Indentation standard
INTEGERS
Please avoid to use long ints. This is the source of many compatibility
- problems betwwen 32 bits and 64 bits archs. Either use plain ints (generally
- 32 bits width) or long long ints (64 bits width, at least). At last resort
+ problems between 32 bits and 64 bits archs. Either use plain ints (generally
+ 32 bits wide) or long long ints (64 bits wide, at least). At last resort
consider using integer types defined in C99 by <stdint.h>.
PRINTF pointer difference (FIXME: advertise %td instead?)
deactivate the whole logging mechanism, switching to printfs
instead. SimGrid becomes incredibly verbose when doing so, but it
you let you fixing the dynars.
-
\ No newline at end of file