----------------------------------------------------------------------
---------------------- main() generation -----------------------------
----------------------------------------------------------------------
-
-/** \page GRAS_main_generation main() and GRAS
-
- <center>[\ref GRAS_API]</center>
-
- \section GRAS_maingen_toc Table of content
-
- - \ref GRAS_maingen_intro
- - \ref GRAS_maingen_script
- - \ref GRAS_maingen_make
-
- <hr>
-
- \section GRAS_maingen_intro What's the matter with main() functions in GRAS?
-
- In simulation mode, all processes are run as thread of the same process
- while they are real processes in the real life. Unfortunately, the main
- function of a real process must be called <tt>main</tt> while this
- function must not use this name for threads.
-
- To deal with this, you should call the main function of your processes
- with another name (usually, the process function such as client, server,
- or such). Then GRAS can generate the wrapper functions adapted to the
- real and simulated modes.
-
- \section GRAS_maingen_script Generating the main()s automatically
-
- This is done by the gras_stub_generator program, which gets installed on
- <tt>make install</tt> (the source resides in the tools/gras/ directory).
- Here is the calling syntax:
- \verbatim gras_stub_generator <project_name> <deployment_file.xml>\endverbatim
-
- It parses the deployment file, searching for all the kind of processes
- you have in your project. It then generates the following C files:
- - a <tt>_<project_name>_<process_kind>.c</tt> file for each process kind you
- have\n
- They are used to launch your project in real life. They
- contain a main() in charge of initializing the GRAS infrastructure and
- launching your code afterward.
- - a <tt>_<project_name>_simulator.c</tt> file.\n
- This file is suited to the simulation mode. It contains a main()
- function initializing the simulator and launching your project within.
-
- For this to work, the name of process described in your deployment file
- should match the name of a function in your code, which prototype is for
- example: \verbatim int client(int argc,char *argv[]);\endverbatim
-
- Unfortunately, all this is still partially documented. I guess I ought
- to improve this situation somehow. In the meanwhile, check the generated
- code and maybe also the GRAS \ref GRAS_example, sorry.
-
- \section GRAS_maingen_make Integration within an hand-made Makefile
-
- The easiest to set it up is to add the following chunk at the end of
- your Makefile (or Makefile.am), putting the right values into NAME and
- PROCESSES.
-\verbatim NAME=your_project_name
- PROCESSES=list of processes type in your project
-
- $(foreach proc, $(PROCESSES), _$(NAME)_$(proc).c) _$(NAME)_simulator.c: $(NAME).c $(NAME)_deployment.xml
- path/to/gras_stub_generator $(NAME) $(NAME)_deployment.xml >/dev/null
-\endverbatim
-
- Of course, your personal millage may vary. For the \ref GRAS_ex_ping, may read:
-\verbatim _ping_client.c _ping_server.c _ping_simulator.c: ping.c ping_deployment.xml
- $(top_srcdir)/tools/gras/gras_stub_generator ping ping_deployment.xml >/dev/null
-\endverbatim
-
- \warning
- Actually, gras_stub_generator also generates some makefiles both for
- local compilation and remote code distribution and installation. See the
- section \ref GRAS_compile for more details.
-
-*/
-
----------------------------------------------------------------------
-------------------------- Compiling ---------------------------------
----------------------------------------------------------------------
-
-/** \page GRAS_compile Compiling your GRAS project
-
- <center>[\ref GRAS_API]</center>