X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/fc4c9e6585b6a410714badd79c11aee90a298165..c11ff67e793ea2ba851d7bad5ab3fbbc937e48b3:/README.coding diff --git a/README.coding b/README.coding index b4f2b2f697..c0325a7f47 100644 --- a/README.coding +++ b/README.coding @@ -3,81 +3,60 @@ ** ****************************************************** -There is 4 projects in the tree: - - - GROS: no fancy name yet (low-level toolbox: logging, datatypes). - - GRAS: Grid Reality And Simulation (message passing API with two - implementations allowing to compile programs on top of the - simulator or for the real life without code modification) - - SURF: Server for the Use of Resource Fictions (the simulator used - in GRAS and more) - - AMOK: Advanced Metacomputing Overlay Kit (high level toolbox; Grid - application elements such as distributed database, topology - discovery service, and so on) - -They are all in the same tree because GRAS depends on SURF which depends on -GRAS (that's the only cycle here, we're not *that* vicious). - -The tree is not splited on projects, but on file finality: - include/ -> all *public* headers - include/gros/*.h -> one file per module - include/gros.h -> file including all modules headers - (same for gras, surf and amok instead of gros) - - src/Makefile.am -> main makefile. All projects should fit in only one - library (I mean 2, RL+SG), which is compiled here. - - Since all object.o files are placed here, you should - choose the name of c files carfully to avoid - conflict. - - src/gras/DataDesc -> typical project module - src/gras/DataDesc/datadesc_interface.h -> visible to any GRAS modules; - masked to the user and GROS/AMOK/SURF - src/gras/DataDesc/datadesc_private.h -> visible only from this module - - So, the modules have 3 levels of publicity for their interface. - Private, internal to GRAS, public. Of course, I try to keep as much stuff - private as possible. - - 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'. - They are not listed directly in the check_PROGRAMS part of - the makefile because run_test knows about the gras logging - features and relaunch with full details the failed tests. - 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. + +** +** NEW type naming standard in SimGrid4 +** +***************************************************** + +SimGrid4 will follow the these rules: + + - filenames are unique in the whole project + (because of a bug in Sonar coverage computation) + C++ + - fields, methods and variables are in snake_case() + - Classes and Enum are in CamelCase + - filenames: Class.cpp and Class.hpp + C + - variables and functions are in snake_case() + - typedefs do not hide the pointers, ie * must be explicit + char * sg_host_get_name(sg_host_t * host); + + +This is different from the old convention (described below), that +should not be used in S4U and its bindings, nor in the kernel. + ** -** Type naming standard +** OLD Type naming standard in SimGrid3 ** ***************************************************** -It may sound strange, but the type naming convention was source of intense -discution between da GRAS 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. +SimGrid3 legacy interfaces (ie, MSG and SimDag) are following these rules: - - ???_t is a valid type (builded with typedef) + - ???_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). -Exemple: +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. @@ -85,22 +64,31 @@ 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). ** -** Random bits about coding standards and portability +** Commenting the source: doxygen ** -***************************************************** +**************************************************** -MALLOC: - You must cast the result of malloc on AIX. - It's even better to use gras_new when possible. +The global structure of the documentation is in doc/modules.doc -SIZE_T - If possible, avoid size_t and use unsigned long instead. If not, +The structure of each module (xbt, msg, etc) is in doc/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. - #include in all files manipulating size_t - do cast it to unsigned long before printing (and use %lu) - -PRINTF pointer difference - printf ("diff = %ld\n", (long) (pointer2 - pointer1)); - - +* +* 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.