**
** Source tree organization
**
******************************************************

 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.

**
** Type naming standard
**
*****************************************************

It may sound strange, but the type naming convention was source of intense
discussion between da SimGrid posse members. The convention we came to may not
be the best solution, but it has the merit to exist and leave everyone work.
So please stick to it.

  - ???_t is a valid type (built with typedef)
  - s_toto_t is a structure (access to fields with .)
  - s_toto   is a structure needing 'struct' keyword to be used
  - e_toto_t is an enum
  - u_toto_t is an union
  - u_toto   is an union needing 'union' keyword to be used
  -   toto_t is an 'object' (struct*)

Please to not call toto_t something else than an 'object' (ie, something you
have to call _new and _free on it).

Example:
  typedef struct s_toto {} s_toto_t, *toto_t;
  typedef enum {} e_toto_t;

Moreover, only toto_t (and e_toto_t) are public. The rest (mainly s_toto_t)
is private.

If you see any part of the code not following this convention, this is a
bug. Please report it (or fix it yourself if you can).

**
** Commenting the source: doxygen
**
****************************************************

The global structure of the documentation is in doc/modules.doc

The structure of each module (xbt, msg, etc) is in doc/module-<module>.doc

The structure of a module is in its public header. This way, you're sure to
see all the public interface (and only it). The different parts of the
interface are grouped using the @name construct, even if it's buggy. Since
parts often get reordered, it's better to add numbers to the parts (so that
users can see the intended order).

The documentation of each type and macro are also in the public header since
this is were they live.

The documentation of each function must be in the C file were it lives.

Any public element (function, type and macro) must have a @brief part.


*
* SimGrid Hacker Survival Guide (FIXME: should be betterly placed)
********************************
* When you add/remove files, and/or make changes in the lists of files to build,
  please check that "make distcheck" still succeeds.  This is needed to ensure
  that the generated archive is consistent.