Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
update the double extern declaration bis
[simgrid.git] / doc / FAQ.doc
index c7e05cb..0fd24d4 100644 (file)
@@ -89,23 +89,36 @@ command that resides in the top of the source tree. Then just follow the
 instructions of Section \ref faq_compiling.
 
 We insist on the fact that you really need the latest versions of
-autoconf and automake. Doing this step on exotic architectures/systems
+autoconf, automake and libtool. Doing this step on exotic architectures/systems
 (i.e. anything different from a recent linux distribution) may be
-... uncertain. If you want to use the CVS version on another
-architecture/system, you should do the previous steps on a perfectly
-standard box, then do a <tt>make dist</tt> that will build you a
-perfectly portable SimGrid archive.
+... uncertain. If you need to compile the CVS version on a machine where all these
+dependencies are not met, the easiest is to do <tt>make dist</tt> in the CVS
+dir of another machine where all dependencies are met. It will create an
+archive you may deploy on other sites just as a regular stable release.
 
 In summary, the following commands will checkout the CVS, regenerate the
-configure script and friends, configure SimGrid and build an archive you can
-use on another machine afterward.
+configure script and friends, configure SimGrid and build it.
 
 \verbatim cvs -d :pserver:anonymous@scm.gforge.inria.fr:/cvsroot/simgrid login
 cvs -d :pserver:anonymous@scm.gforge.inria.fr:/cvsroot/simgrid checkout simgrid
 cd simgrid
 ./bootstrap
-./configure --enable-maintainer-mode
-make dist \endverbatim
+./configure --enable-maintainer-mode --prefix=<where to install SimGrid>
+make \endverbatim
+
+Then, if you want to install SimGrid on the current box, just do:
+\verbatim make install \endverbatim
+
+If you want to build an snapshot of the CVS to deploy it on another box (for
+example because the other machine don't have the autotools), do:
+\verbatim make dist \endverbatim
+
+Moreover, you should never call the autotools manually since you must run
+them in a specific order with specific arguments. Most of the times, the
+makefiles will automatically call the tools for you. When it's not possible
+(such as the first time you checkout the CVS), use the ./bootstrap command
+to call them explicitely.
+
 
 \subsection faq_setting_MSG Setting up your own MSG code
 
@@ -238,11 +251,12 @@ in the meanwhile, simply don't build the examples in cross-compilation
 Program (cross-)compiled with mingw32 do request an extra DLL at run-time to be
 usable. For example, if you want to test your build with wine, you should do
 the following to put this library where wine looks for DLLs.
-\verbatim  cp /usr/share/doc/mingw32-runtime/mingwm10.dll.gz ~/.wine/c/windows/system/
+\verbatim 
+cp /usr/share/doc/mingw32-runtime/mingwm10.dll.gz ~/.wine/c/windows/system/
 gunzip ~/.wine/c/windows/system/mingwm10.dll.gz
 \endverbatim
 
-The DLL is builded in src/.libs, and installed in the <prefix>/bin directory
+The DLL is builded in src/.libs, and installed in the <i>prefix</i>/bin directory
 when you run make install. 
 
 If you want to use it in a native project on windows, you need to use 
@@ -253,18 +267,26 @@ generate the def files, run (under linux):
 \verbatim echo "LIBRARY libsimgrid-0.dll" > simgrid.def
 echo EXPORTS >> simgrid.def
 nm libsimgrid-0.dll | grep ' T _' | sed 's/.* T _//' >> simgrid.def
+nm libsimgrid-0.dll | grep ' D _' | sed 's/.* D _//' | sed 's/$/ DATA/' >> simgrid.def
 
 echo "LIBRARY mingwm10.dll" > mingwm10.def
 echo EXPORTS >> mingwm10.def
 nm mingwm10.dll | grep ' T _' | sed 's/.* T _//' >> mingwm10.def
+nm mingwm10.dll | grep ' D _' | sed 's/.* D _//' | sed 's/$/ DATA/' >> mingwm10.def
 \endverbatim
 
-To create the import .lib files, use the <tt>lib</tt> windows tool the
-following way to produce simgrid.lib and mingwm10.lib
+To create the import .lib files, use the <tt>lib</tt> windows tool (from
+MSVC) the following way to produce simgrid.lib and mingwm10.lib
 \verbatim lib /def:simgrid.def
 lib /def:mingwm10.def
 \endverbatim
 
+If you happen to use Borland C Builder, the right command line is the
+following (note that you don't need any file.def to get this working).
+\verbatim implib simgrid.lib libsimgrid-0.dll
+implib mingwm10.lib mingwm10.dll
+\endverbatim
+
 Then, set the following parameters in Visual C++ 2005:
 Linker -> Input -> Additional dependencies = simgrid.lib mingwm10.lib
 
@@ -458,12 +480,20 @@ even take the currently running tasks into account. In some SURF models,
 communications have an influence on computational power. Should it be taken
 into account too?
 
-So, we decided not to include such a function into MSG and let people do it
-thereselves so that they get the value matching exactly what they mean. One
-possibility is to run active measurement as in next code snippet. It is very
-close from what you would have to do out of the simulator, and thus gives
-you information that you could also get in real settings to not hinder the
-realism of your simulation. 
+First of all, it's near to impossible to predict the load beforehands in the
+simulator since it depends on too much parameters (background load
+variation, bandwidth sharing algorithmic complexity) some of them even being
+not known beforehands (other task starting at the same time). So, getting
+this information is really hard (just like in real life). It's not just that
+we want MSG to be as painful as real life. But as it is in some way
+realistic, we face some of the same problems as we would face in real life.
+
+How would you do it for real? The most common option is to use something
+like NWS that performs active probes. The best solution is probably to do
+the same within MSG, as in next code snippet. It is very close from what you
+would have to do out of the simulator, and thus gives you information that
+you could also get in real settings to not hinder the realism of your
+simulation. 
 
 \verbatim
 double get_host_load() {
@@ -1051,6 +1081,17 @@ These are changes to FleXML itself, not SimGrid. But since we kinda hijacked
 the development of FleXML, I can grant you that any patches would be really
 welcome and quickly integrated.
 
+<b>Update:</b> A new version of FleXML (1.7) was released. Most of the work
+was done by William Dowling, who use it in his own work. The good point is
+that it now use a dynamic buffer, and that the memory usage was greatly
+improved. The downside is that William also changed some things internally,
+and it breaks the hack we devised to bypass the parser, as explained in 
+\ref faq_flexml_bypassing. Indeed, this is not a classical usage of the
+parser, and Will didn't imagine that we may have used (and even documented)
+such a crude usage of FleXML. So, we now have to repare the bypassing
+functionnality to use the lastest FleXML version and fix the memory usage in
+SimGrid.
+
 \subsection faq_gras_transport GRAS spits networking error messages
 
 Gras, on real platforms, naturally use regular sockets to communicate. They