From 8fb46a312e49dbbb5ba41a79364ff0390563c9eb Mon Sep 17 00:00:00 2001 From: Martin Quinson Date: Fri, 1 Mar 2019 23:46:34 +0100 Subject: [PATCH] kill obsolete doc There is no need to convert that. --- doc/doxygen/FAQ.doc | 219 +----- doc/doxygen/footer.html | 20 - doc/doxygen/header.html | 59 -- doc/doxygen/index.doc | 64 -- doc/doxygen/inside_cmake.doc | 121 +--- doc/doxygen/inside_doxygen.doc | 224 ------ doc/doxygen/module-xbt.doc | 15 - doc/doxygen/outcomes_MC.doc | 6 - doc/doxygen/stylesheet.css | 1140 ------------------------------ tools/cmake/DefinePackages.cmake | 6 - 10 files changed, 14 insertions(+), 1860 deletions(-) delete mode 100644 doc/doxygen/footer.html delete mode 100644 doc/doxygen/header.html delete mode 100644 doc/doxygen/index.doc delete mode 100644 doc/doxygen/inside_doxygen.doc delete mode 100644 doc/doxygen/outcomes_MC.doc delete mode 100644 doc/doxygen/stylesheet.css diff --git a/doc/doxygen/FAQ.doc b/doc/doxygen/FAQ.doc index 96c9811a11..5b902f4f1c 100644 --- a/doc/doxygen/FAQ.doc +++ b/doc/doxygen/FAQ.doc @@ -88,54 +88,6 @@ it with MSG. Feel free to contribute... @subsection faq_MIA_MSG MSG features -@subsubsection faq_MIA_examples I want some more complex MSG examples! - -Many people have come to ask me a more complex example and each time, -they have realized afterward that the basics were in the previous three -examples. - -Of course they have often been needing more complex functions like -MSG_process_suspend(), MSG_process_resume() and -MSG_process_isSuspended() (to perform synchronization), or -MSG_task_Iprobe() and MSG_process_sleep() (to avoid blocking -receptions), or even MSG_process_create() (to design asynchronous -communications or computations). But the examples are sufficient to -start. - -We know. We should add some more examples, but not really some more -complex ones... We should add some examples that illustrate some other -functionalists (like how to simply encode asynchronous -communications, RPC, process migrations, thread synchronization, ...) -and we will do it when we will have a little bit more time. We have -tried to document the examples so that they are understandable. Tell -us if something is not clear and once again feel free to participate! -:) - -@subsubsection faq_MIA_taskdup Missing in action: MSG Task duplication/replication - -There is no task duplication in MSG. When you create a task, you can -process it or send it somewhere else. As soon as a process has sent -this task, he doesn't have this task anymore. It's gone. The receiver -process has got the task. However, you could decide upon receiving to -create a "copy" of a task but you have to handle by yourself the -semantic associated to this "duplication". - -As we already told, we prefer keeping the API as simple as -possible. This kind of feature is rather easy to implement by users -and the semantic you associate really depends on people. Having a -*generic* task duplication mechanism is not that trivial (in -particular because of the data field). That is why I would recommend -that you write it by yourself even if I can give you advice on how to -do it. - -You have the following functions to get information about a task: -MSG_task_get_name(), MSG_task_get_compute_duration(), -MSG_task_get_remaining_computation(), MSG_task_get_data_size(), -and MSG_task_get_data(). - -You could use a dictionary (#xbt_dict_t) of dynars (#xbt_dynar_t). If -you still don't see how to do it, please come back to us... - @subsubsection faq_MIA_thread_synchronization How to synchronize my user processes? It depends on why you want to synchronize them. If you just want to @@ -173,51 +125,6 @@ mailboxes. Typically, if you need one process to notify another one, you could use a condition variable or a semphore, but sending a message to a specific mailbox does the trick in most cases. -@subsubsection faq_MIA_host_load Where is the get_host_load function hidden in MSG? - -There is no such thing because its semantic wouldn't be really -clear. Of course, it is something about the amount of host throughput, -but there is as many definition of "host load" as people asking for -this function. First, you have to remember that resource availability -may vary over time, which make any load notion harder to define. - -It may be instantaneous value or an average one. Moreover it may be only the -power of the computer, or may take the background load into account, or may -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? - -First of all, it's near to impossible to predict the load beforehand in the -simulator since it depends on too much parameters (background load -variation, bandwidth sharing algorithmic complexity) some of them even being -not known beforehand (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. - -@code -double get_host_load() { - m_task_t task = MSG_task_create("test", 0.001, 0, NULL); - double date = MSG_get_clock(); - - MSG_task_execute(task); - date = MSG_get_clock() - date; - MSG_task_destroy(task); - return (0.001/date); -} -@endcode - -Of course, it may not match your personal definition of "host load". In this -case, please detail what you mean on the mailing list, and we will extend -this FAQ section to fit your taste if possible. - @subsubsection faq_MIA_communication_time How can I get the *real* communication time? Communications are synchronous and thus if you simply get the time @@ -368,20 +275,9 @@ You should refer to the Platform Description Archive have available, as well as the Simulacrum simulator, meant to generate SimGrid platforms using all classical generation algorithms. -@subsubsection faq_platform_alnem How can I automatically map an existing platform? - -We are working on a project called ALNeM (Application-Level Network -Mapper) which goal is to automatically discover the topology of an -existing network. Its output will be a platform description file -following the SimGrid syntax, so everybody will get the ability to map -their own lab network (and contribute them to the catalog project). -This tool is not ready yet, but it move quite fast forward. Just stay -tuned. - @subsubsection faq_platform_synthetic Generating synthetic but realistic platforms -The third possibility to get a platform file (after manual or -automatic mapping of real platforms) is to generate synthetic +Another possibility to get a platform file is to generate synthetic platforms. Getting a realistic result is not a trivial task, and moreover, nobody is really able to define what "realistic" means when speaking of topology files. You can find some more thoughts on this @@ -401,46 +297,6 @@ tasks on the host, each will get half of the computing power. Please note that although sound, this model were never scientifically assessed. Please keep this fact in mind when using it. - -@subsubsection faq_platform_random Using random variable for the resource power or availability - -The best way to model the resouce power using a random variable is to -use an availability trace that is directed by a probability -distribution. This can be done using the function -tmgr_trace_generator_value() below. The date and value generators is -created with one of tmgr_event_generator_new_uniform(), -tmgr_event_generator_new_exponential() or -tmgr_event_generator_new_weibull() (if you need other generators, -adding them to src/surf/trace_mgr.c should be quite trivial and your -patch will be welcomed). Once your trace is created, you have to -connect it to the resource with the function -sg_platf_new_trace_connect(). - -That the process is very similar if you want to model the -resource availability with a random variable (deciding whether it's -on/off instead of deciding its speed) using the function -tmgr_trace_generator_state() or tmgr_trace_generator_avail_unavail() -instead of tmgr_trace_generator_value(). - -Unfortunately, all this is currently lacking a proper documentation, -and there is even no proper example of use. You'll thus have to check -the header file include/simgrid/platf.h and experiment a bit by -yourself. The following code should be a good starting point, and -contributing a little clean example would be a good way to help the -SimGrid project. - -@code -tmgr_trace_generator_value("mytrace",tmgr_event_generator_new_exponential(.5) - tmgr_event_generator_new_uniform(100000,9999999)); - -sg_platf_trace_connect_cbarg_t myconnect = SG_PLATF_TRACE_CONNECT_INITIALIZER; -myconnect.kind = SURF_TRACE_CONNECT_KIND_BANDWIDTH; -myconnect.trace = "mytrace"; -myconnect.element = "mylink"; - -sg_platf_trace_connect(myconnect); -@endcode - @section faq_troubleshooting Troubleshooting @subsection faq_trouble_changelog The feature X stopped to work after my last update @@ -458,33 +314,6 @@ should update to the new way of doing things, but if you can't afford it, that's ok. Just stick to the last version that were working for you, and have a pleasant day. -@subsection faq_trouble_lib_compil SimGrid compilation and installation problems - -@subsubsection faq_trouble_lib_config cmake fails! - -We know only one reason for the configure to fail: - - - You are using a broken build environment@n - Try updating your cmake version. If symptom is that the configury - magic complains about gcc not being able to build executables, you - are probably missing the libc6-dev package. Damn Ubuntu. - -If you experience other kind of issue, please get in touch with us. We are -always interested in improving our portability to new systems. - -@subsubsection faq_trouble_distcheck Dude! "ctest" fails on my machine! - -Don't assume we never run this target, because we do. Check -http://cdash.inria.fr/CDash/index.php?project=Simgrid (click on -previous if there is no result for today: results are produced only by -11am, French time) and -https://buildd.debian.org/status/logs.php?pkg=simgrid if you don't believe us. - -If it's failing on your machine in a way not experienced by the -autobuilders above, please drop us a mail on the mailing list so that -we can check it out. Make sure to read @ref faq_bugrepport before you -do so. - @subsection faq_trouble_compil User code compilation problems @subsubsection faq_trouble_err_logcat "gcc: _simgrid_this_log_category_does_not_exist__??? undeclared (first use in this function)" @@ -543,52 +372,6 @@ Both options are needed in order to run the SMPI process under GDB. If you don't, you really should use valgrind to debug your code, it's almost magic. -@subsubsection faq_trouble_vg_libc Valgrind spits tons of errors about backtraces! - -It may happen that valgrind, the memory debugger beloved by any decent C -programmer, spits tons of warnings like the following : -@verbatim ==8414== Conditional jump or move depends on uninitialised value(s) -==8414== at 0x400882D: (within /lib/ld-2.3.6.so) -==8414== by 0x414EDE9: (within /lib/tls/i686/cmov/libc-2.3.6.so) -==8414== by 0x400B105: (within /lib/ld-2.3.6.so) -==8414== by 0x414F937: _dl_open (in /lib/tls/i686/cmov/libc-2.3.6.so) -==8414== by 0x4150F4C: (within /lib/tls/i686/cmov/libc-2.3.6.so) -==8414== by 0x400B105: (within /lib/ld-2.3.6.so) -==8414== by 0x415102D: __libc_dlopen_mode (in /lib/tls/i686/cmov/libc-2.3.6.so) -==8414== by 0x412D6B9: backtrace (in /lib/tls/i686/cmov/libc-2.3.6.so) -==8414== by 0x8076446: xbt_dictelm_get_ext (dict_elm.c:714) -==8414== by 0x80764C1: xbt_dictelm_get (dict_elm.c:732) -==8414== by 0x8079010: xbt_cfg_register (config.c:208) -==8414== by 0x806821B: MSG_config (msg_config.c:42) -@endverbatim - -This problem is somewhere in the libc when using the backtraces and there is -very few things we can do ourselves to fix it. Instead, here is how to tell -valgrind to ignore the error. Add the following to your ~/.valgrind.supp (or -create this file on need). Make sure to change the obj line according to -your personnal mileage (change 2.3.6 to the actual version you are using, -which you can retrieve with a simple "ls /lib/ld*.so"). - -@verbatim { - name: Backtrace madness - Memcheck:Cond - obj:/lib/ld-2.3.6.so - fun:dl_open_worker - fun:_dl_open - fun:do_dlopen - fun:dlerror_run - fun:__libc_dlopen_mode -}@endverbatim - -Then, you have to specify valgrind to use this suppression file by passing -the --suppressions=$HOME/.valgrind.supp option on the command line. -You can also add the following to your ~/.bashrc so that it gets passed -automatically. Actually, it passes a bit more options to valgrind, and this -happen to be my personnal settings. Check the valgrind documentation for -more information. - -@verbatim export VALGRIND_OPTS="--leak-check=yes --leak-resolution=high --num-callers=40 --tool=memcheck --suppressions=$HOME/.valgrind.supp" @endverbatim - @subsubsection faq_trouble_backtraces Truncated backtraces When debugging SimGrid, it's easier to pass the diff --git a/doc/doxygen/footer.html b/doc/doxygen/footer.html deleted file mode 100644 index 80222ad953..0000000000 --- a/doc/doxygen/footer.html +++ /dev/null @@ -1,20 +0,0 @@ - - - - - -
-$generatedby   -doxygen - $doxygenversion -
- - - diff --git a/doc/doxygen/header.html b/doc/doxygen/header.html deleted file mode 100644 index 12bef2e57b..0000000000 --- a/doc/doxygen/header.html +++ /dev/null @@ -1,59 +0,0 @@ - - - - - -$projectname: $title -$title - - - -$treeview -$search -$mathjax - - - -
- - -
- - - - - - - - - - - - - - - - - - -
-
$projectname -  $projectnumber -
-
$projectbrief
- 		-
$projectbrief
-
-
- - - - diff --git a/doc/doxygen/index.doc b/doc/doxygen/index.doc deleted file mode 100644 index a515c11887..0000000000 --- a/doc/doxygen/index.doc +++ /dev/null @@ -1,64 +0,0 @@ -/*! -@mainpage SimGrid User Documentation - -@image html simgrid_logo_2011.png "Versatile Simulation of Distributed Systems, for Grids, Clouds, P2P and HPC systems" -@image latex simgrid_logo_2011.png "Versatile Simulation of Distributed Systems, for Grids, Clouds, P2P and HPC systems" - -@htmlonly -


- -
-@endhtmlonly - -- @subpage getting_started - - @subpage install - - @subpage install_yours - - @subpage tutorial_msg "Tutorial with MSG" - - @subpage tutorial_smpi "Tutorials with SMPI" -- @subpage application - - @subpage s4u_api - - @subpage SMPI_API - - @subpage MSG_API - - @subpage SD_API - - @subpage MSG_Java -- @subpage platform - - @subpage models - - @subpage platform_lua - - @subpage pls_ns3 -- @subpage scenario - - @subpage deployment - - @subpage options -- @subpage outcomes - - @subpage outcomes_logs - - @subpage outcomes_vizu - - @subpage outcomes_MC -- @subpage howto - - Energy, Clouds - - Scalability Tweaks - - @subpage examples -- @subpage uhood - - @subpage uhood_arch - - Simulating Resource Sharing - - @subpage uhood_switch - - @subpage uhood_tech -- @subpage community - - @subpage community_contact - - @subpage community_giveback - - @subpage community_extend -- @subpage FAQ - -@htmlonly - -@endhtmlonly - -\htmlinclude graphical-toc.svg - -
SimGrid Usage (click to jump to the relevant parts) - -@htmlonly -
-@endhtmlonly - -*/ - - diff --git a/doc/doxygen/inside_cmake.doc b/doc/doxygen/inside_cmake.doc index 6f31b641cb..61e85f7acc 100644 --- a/doc/doxygen/inside_cmake.doc +++ b/doc/doxygen/inside_cmake.doc @@ -3,50 +3,15 @@ @tableofcontents -SimGrid uses CMake which is a family of tools designed to build, test, and package software. CMake is used to control the software -compilation process using simple platform- and compiler-independent configuration files. CMake generates native -makefiles and workspaces that can be used in the compiler environment of your choice. For more information see -the official CMake web site. +SimGrid uses CMake which is a family of tools designed to build, test, and package software. @section inside_cmake_addsrc How to add source files? If you want to rename, add, or delete source file(s) in the SimGrid distribution, you have to edit the -$SIMGRID_INSTALL_PATH/tools/cmake/DefinePackages.cmake configuration file. Files are organized in sections, then find -the section you are interested in and modify it. For instance, a new S4U source file will have to be listed in: +tools/cmake/DefinePackages.cmake configuration file. Files are organized in sections, then find +the section you are interested in and modify it. -@verbatim -set(S4U_SRC - src/s4u/s4u_actor.cpp - src/s4u/s4u_as.cpp - src/s4u/s4u_activity.cpp - src/s4u/s4u_comm.cpp - src/s4u/s4u_engine.cpp - src/s4u/s4u_file.cpp - src/s4u/s4u_host.cpp - src/s4u/s4u_mailbox.cpp - src/s4u/s4u_storage.cpp -) -@endverbatim - -If sources file always have to be included into the library, you are all set. However, ther inclusion may depend on -specific compiling options. For instance, if Boost contexts are not available, you don't want to compile the -src/simix/ContextBoost.* files but still add them to the source distribution. This is done by adding those files to the - EXTRA_DIST list, as follows: - -@verbatim -if (HAVE_BOOST_CONTEXTS) - set(SIMIX_SRC ${SIMIX_SRC} src/simix/ContextBoost.hpp - src/simix/ContextBoost.cpp) -else() - set(EXTRA_DIST ${EXTRA_DIST} src/simix/ContextBoost.hpp - src/simix/ContextBoost.cpp) -endif() -@endverbatim - -Once you're done, you must run "make distcheck" to ensure that you did not forget to add any file to the distributed -archives. This ensures that everything was commited correctly, so you have to first commit before running -"make distcheck". If you forgot something, you want to "git commit --amend". But never amend a commit that you already -pushed to public repositories! Do a second commit in that case. +Once you're done, test your changes with ``make distcheck``. @section inside_cmake_examples How to add an example? @@ -59,79 +24,19 @@ To ensure that all examples actually work as expected, every example is also use users. In particular, torture test cases should be placed in teshsuite/, not examples/, so that the users don't stumble upon them by error. -To add a new example, the first thing is to find the right place to add it. The examples/ directory is organized as -follows: +The examples/ directory is organized as follows: + - examples/s4u/ for examples using the emerging S4U API + - examples/smpi/ or examples using the SMPI API + - examples/platforms/ only contains platforms descriptions in the XML format (see @ref platform for details) + - examples/deprecated/msg/ for examples using the MSG API. Here the naming convention is package-example (e.g., app-masterworker). + - examples/deprecated/simdag/ for examples using the SimDag API - examples/deprecated/java/ for examples using the Java bindings to the MSG API. This directory contains packages (app, async, cloud, ...) which in turn contain individual examples. If your new example fits in an existing package, add it here, or create a new package otherwise. - - examples/deprecated/msg/ for examples using the MSG API. Here the naming convention is package-example (e.g., app-masterworker). - Again, please try to fit to an existing package before creating a new one. - - examples/platforms/ only contains platforms descriptions in the XML format (see @ref platform for details) - - examples/s4u/ for examples using the emerging S4U API - - examples/deprecated/simdag/ for examples using the SimDag API - - examples/smpi/ or examples using the SMPI API - -In each of these directories, there is a CMakeLists.txt file that has to be edited to include the new examples. For -instance, examples/deprecated/msg/CMakeLists.txt starts with a loop over all the (currently) existing tests in which we - - compile and link the source file (which has to be named as the directory - - add the source and tesh files to the distribution. - -@verbatim -foreach(x app-masterworker app-pingpong app-pmm app-token-ring async-wait async-waitall - async-waitany cloud-capping cloud-masterworker cloud-migration cloud-multicore cloud-simple - cloud-two-tasks dht-chord dht-pastry energy-consumption energy-onoff energy-pstate energy-ptask energy-vm - platform-failures io-file io-remote io-storage task-priority process-create process-kill process-migration - process-suspend platform-properties maestro-set process-startkilltime synchro-semaphore trace-categories - trace-link-srcdst-user-variables trace-link-user-variables trace-masterworker trace-platform - trace-process-migration trace-user-variables) - add_executable (${x} ${x}/${x}.c) - target_link_libraries(${x} simgrid) - set_target_properties(${x} PROPERTIES RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/${x}) - set(examples_src ${examples_src} ${CMAKE_CURRENT_SOURCE_DIR}/${x}/${x}.c) - set(tesh_files ${tesh_files} ${CMAKE_CURRENT_SOURCE_DIR}/${x}/${x}.tesh) -endforeach() -@endverbatim - -Some more complex examples may require more than one source file. If it is the case for your example, you will find -inspiration in the following example - -@verbatim -add_executable (bittorrent app-bittorrent/bittorrent.c app-bittorrent/messages.c app-bittorrent/peer.c app-bittorrent/tracker.c app-bittorrent/connection.c) -target_link_libraries(bittorrent simgrid) -set_target_properties(bittorrent PROPERTIES RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/app-bittorrent) -foreach (file bittorrent connection messages peer tracker) - set(examples_src ${examples_src} ${CMAKE_CURRENT_SOURCE_DIR}/app-bittorrent/${file}.c ${CMAKE_CURRENT_SOURCE_DIR}/app-bittorrent/${file}.h) -endforeach() -@endverbatim - -If your example require a deployment file (see @ref deployment for details), name it as the source file adding "_d.xml". -Then add the name of your example to this foreach loop. - -@verbatim -foreach (file app-bittorrent app-chainsend app-masterworker app-pingpong async-wait - async-waitall async-waitany dht-chord dht-kademlia dht-pastry io-remote platform-properties maestro-set - task-priority) - set(xml_files ${xml_files} ${CMAKE_CURRENT_SOURCE_DIR}/${file}/${file}_d.xml) -endforeach() -@endverbatim - -If your example includes extra source, text, XML, or tesh files, add them to the existing lists. Finally, register your -example to the testing infrastructure. See @ref inside_tests_add_integration for more details. -@verbatim -foreach(x app-bittorrent app-chainsend app-masterworker app-pingpong app-token-ring - async-wait async-waitall async-waitany cloud-capping cloud-masterworker cloud-migration cloud-simple - cloud-two-tasks dht-chord dht-kademlia platform-failures io-file io-remote io-storage task-priority - process-kill process-migration process-suspend platform-properties synchro-semaphore process-startkilltime) - ADD_TESH_FACTORIES(msg-${x} "thread;ucontext;raw;boost" --setenv bindir=${CMAKE_BINARY_DIR}/examples/deprecated/msg/${x} --setenv srcdir=${CMAKE_HOME_DIRECTORY}/examples/platforms --cd ${CMAKE_HOME_DIRECTORY}/examples/deprecated/msg/${x} ${x}.tesh) -endforeach() -@endverbatim +In each of these directories, there is a CMakeLists.txt file that has +to be edited to include the new examples. -Note that the structure of the CMakeLists.txt file may vary from one directory to another, but there are enough existing -examples to find one that can be adapted to your own example. +Once you're done, test your changes with ``make distcheck``. -Once you're done, you must run "make distcheck" to ensure that you did not forget to add any file to the distributed -archives. This ensures that everything was commited correctly, so you have to first commit before running -"make distcheck". If you forgot something, you want to "git commit --amend". But never amend a commit that you already -pushed to public repositories, or you'll break the checkouts of your fellow co-workers! Do a second commit in that case. */ diff --git a/doc/doxygen/inside_doxygen.doc b/doc/doxygen/inside_doxygen.doc deleted file mode 100644 index eec1065d69..0000000000 --- a/doc/doxygen/inside_doxygen.doc +++ /dev/null @@ -1,224 +0,0 @@ -/*! -@page inside_doxygen Documenting SimGrid - -@tableofcontents - -We use doxygen for our documentation. It's annoying but that's the -best we've found so far. Stop bitching about the doc or the tools, and -start improving the documentation text itself. - -Good documentation is rare and there is not much project of which we -can get inspiration. The best exception I know is TikZ and -latex-beamer. I'd be so happy if SimGrid documentation could follow -the organization (and reach half the quality) of the TikZ one. But -anyway. As they say: Documentation is like sex; when it's not good -it's still better than nothing and when it's good it's very very good. - -@section inside_doxygen_module Adding a new module to the reference guide - -If you add a new file to the project, you want to document it. It's -more urgent if it's user-visible, but it should be done in any case if -possible. - -@subsection inside_doxygen_module_create Declaring the module to doxygen - -First declare your sub-module in the corresponding -(project)/doc/doxygen/module-(enclosing module).doc Two edits are -needed in this file: - -@li Most of the enclosing modules (xbt, msg, sd, etc) have a manually - maintained table of contents as content of the module main page, - at the top of the corresponding file. You want to add a reference to - your sub-module there. For that, simply add something like the - following. The dash (-) will help building item lists. The ref - command requests for a link to your module, that is identified - with the word after that (here, I used XBT_str as a sub-module - identifier. -@verbatim - - @ref XBT_str -@endverbatim - -@li Create your module below in the file as follows. the first world -after the defgroup keyword must be the sub-module identifier you used -above. -@verbatim - /** @defgroup XBT_str String related functions */ -@endverbatim -Warning, the location of this block decides where it appears in the -documentation. In particular, the order of the defgroups is not -inocuitous at all. - -@subsection inside_doxygen_module_populate Adding symbols to your module - -Once your group is created and referenced from the group containing -it, you must populate it. For that, edit the corresponding header file -to add something like this near the top. -@verbatim -/** @addtogroup XBT_str - * @brief - * - * - * - * @{ - */ - - - -/** @} */ -@endverbatim - -Any informative stuff is welcomed in the module introduction, on top. -This includes examples that the users can copy/paste to fit their -needs. If your module is too large to be nicely documented on one -unique page, you may want to split its documentation in sub-modules. -See dynar.h for an example of how to do so. - -Make sure to only include the public declarations of your module. For -example, if you have black magic macro voodoo, you probably have some -symbols that are there only for the compiler, but that the users -should not see. In this case, do not put the symbols you want to hide -between the @ { and @ } markers. - -@subsection inside_doxygen_module_document Documenting the symbols of your module - -Finally, you naturally need to actually write the documentation of -each public symbol belonging to your module. Macros must naturally be -documented in the header file, but it is prefered to put the -documentation in the source file, alongside with the actual -implementation. It is expected that when the code changes, the chances -to update the doc accordingly are higher if the documentation is near -to the code. - -For each symbol, you must provide a one-line description in the -brief doxygen parameter. Please document any non trivial -parameter (but something like "dynar: the provided dynar" is not -considered as an informative documentation and can be omitted), and -give any information you feel useful to the user. In particular, add -links to any other location of the documentation that could provide -interesting additional information. - -@section inside_doxygen_page Adding a new page to the user guide - -Note that doxygen provides two hierarchies that cannot be intermixed. -Groups are used to build a reference guide while pages are used for -any other kind of page in the documentation. A module cannot contain -any page, while a page cannot contain any module. That's the doxygen -style. - -@subsection inside_doxygen_page_write Writing a new documentation page - -The first thing to do to add a new page is to actually write a file -containing the information you want to add. It should be located in -(project)/doc/doxygen and be named (something).doc Its content must be -something like the following: - -@verbatim -/** @page - -@tableofcontents - -blah blah blah - -@section <short_name_of_section> <title> - -blah blah blah - -@subsection <short_name_of_subsection> <title> - -Even more stuff. Because we love documentation. We all do. - -*/ -@endverbatim - -Don't forget the starting and ending comment signs. Doxygen only takes -documentation that is in comments, even if there is nothing else in -the file. - -Any short names must be uniq as they are used for the <i>ref</i> -commands to build references between parts. - -Titles should be chosed wisely, as they are used (1) as section -headers (2) in the table of contents (3) as text of references, unless -people building a reference specify a replacement text as in: -@verbatim -@ref shortname "text to use instead of the title" -@endverbatim - -@subsection inside_doxygen_page_doxy Registering a documentation page to doxygen - -Edit (project)/doc/Doxyfile.in and add your page to the INPUT -variable. Don't edit the Doxyfile directly, as it is generated -automatically from the Doxyfile.in: your changes would be overwritten. - -Also, edit the source file of the page that will englob the newly page -(to add a new page at root level, edit index.doc that declares the -root), and add something like the following. - -@verbatim -@subpage <shortname> -@endverbatim - -This allows doxygen to understand about the page hierarchy that you -want to build. It also puts the name of the subpage as a ref would do. -That is why every page in our documentation seem to contain a table of -contents of sub pages even if it dupplicates what's on the left. -That's the doxygen style (but I can live with it). - -@subsection inside_doxygen_page_cmake Registering a documentation page to cmake - -Ahhh, cmake and doxygen. The perfect combo to bitch about life for a -whole day... - -Edit (project)/tools/cmake/DefinePackage.cmake, and add your -newly added page to the DOC_SOURCES. And bitch about these damn tools. - -Don't forget to commit your page, so that you can get some git fun to -complete your day. - -@section inside_doxygen_image Adding an image to the documentation - -If you need to run a command (like fig2dev) to generate your image, -edit tools/cmake/GenerateDoc.cmake and add your command to the -doc target (grep for fig2dev in the file to see -where exactly). Don't forget to add the source of your image to the -archive somehow. You can add it to the list DOC_FIG of -tools/cmake/DefinePackage.cmake. - -If your image is ready to use, put your png in doc/webcruft, and -register it to cmake by adding it to the DOC_IMG list of file -tools/cmake/DefinePackage.cmake so that it lands in the archive -distribution. It will also be copied automatically to the documentation. - -@section inside_doxygen_website Working on the website - -Our website is generated/exported via [orgmode](http://www.orgmode.org), a tool that we use to facilitate our reproducible research. - -Get the sources, and start improving the -website now! (There is a README in the repo with more details, -but it might be outdated. Contact us if you really want to help.) - -@verbatim -git clone git://scm.gforge.inria.fr/simgrid/website.git -@endverbatim - -@section inside_doxygen_regen Regenerating the documentation - -Once you've changed the doc, you want to run doxygen to regenerate the -html output (and maybe the pdf too). Here is how to do this: - -@verbatim -make doc # html documentation -make pdf # the result is in doc/latex/simgrid_documentation.pdf -@endverbatim - -Once you're satisfyied with the result, refreshing the documentation -on the web pages is very easy, as shown below. A few permission errors -are ok, unfortunately. We should improve things here, but I'm not sure -of how. This @c make target is also provided in the archives we -distribute to the users, but I guess that it's harmless :) - -@verbatim -make sync-gforge-doc -@endverbatim - -*/ diff --git a/doc/doxygen/module-xbt.doc b/doc/doxygen/module-xbt.doc index f418de9edb..2c3e4b44bd 100644 --- a/doc/doxygen/module-xbt.doc +++ b/doc/doxygen/module-xbt.doc @@ -79,18 +79,3 @@ /** @defgroup XBT_replay Replay */ /** @} */ -/* ************************* * - * * PORTABILITY-INTERNALS * * (not included in documentation) - * ************************* */ - - /** @addtogroup XBT_context Portable context implementation - * @brief Contexts are a higher level system than <tt>setjump/longjmp</tt> - * for non-preemptible threads. - * - * You shouldn't use it directly since it is merely intended to ease the - * implementation of the several programmation environment of the - * SimGrid toolkit (namely, @ref MSG_API and @ref SMPI_API). - * - * You should use those environments instead. - */ - diff --git a/doc/doxygen/outcomes_MC.doc b/doc/doxygen/outcomes_MC.doc deleted file mode 100644 index 551bc134c1..0000000000 --- a/doc/doxygen/outcomes_MC.doc +++ /dev/null @@ -1,6 +0,0 @@ -/** -@page outcomes_MC Model-Checking - -TBD - -*/ \ No newline at end of file diff --git a/doc/doxygen/stylesheet.css b/doc/doxygen/stylesheet.css deleted file mode 100644 index 9a7f63119b..0000000000 --- a/doc/doxygen/stylesheet.css +++ /dev/null @@ -1,1140 +0,0 @@ -/** These things are used in the header */ -.sgtabs, .sgtabs2, .sgtabs3 { - background-image: url('tab_b.png'); - width: 100%; - z-index: 101; - font-size: 13px; - font-family: 'Lucida Grande',Geneva,Helvetica,Arial,sans-serif; -} - -.sgtabs2 { - font-size: 10px; -} -.sgtabs3 { - font-size: 9px; -} - -.sgtablist { - margin: 0; - padding: 0; - display: table; -} - -.sgtablist li { - float: left; - display: table-cell; - background-image: url('tab_b.png'); - line-height: 36px; - list-style: none; -} - -.sgtablist a { - display: block; - padding: 0 20px; - font-weight: bold; - background-image:url('tab_s.png'); - background-repeat:no-repeat; - background-position:right; - color: #283A5D; - text-shadow: 0px 1px 1px rgba(255, 255, 255, 0.9); - text-decoration: none; - outline: none; -} - -.sgtabs3 .sgtablist a { - padding: 0 10px; -} - -.sgtablist a:hover { - background-image: url('tab_h.png'); - background-repeat:repeat-x; - color: #fff; - text-shadow: 0px 1px 1px rgba(0, 0, 0, 1.0); - text-decoration: none; -} - -.sgtablist li.current a { - background-image: url('tab_a.png'); - background-repeat:repeat-x; - color: #fff; - text-shadow: 0px 1px 1px rgba(0, 0, 0, 1.0); -} -/* End of our tabs */ - -body, table, div, p, dl { - font: 400 14px/19px Roboto,sans-serif; -} - -/* @group Heading Levels */ - -.title { - font-size: 150%; - font-weight: bold; - margin: 10px 2px; -} - -h1, h2, h3 { - color: #354C7B; - font-weight: normal; - display: block; - padding-top: 8px; -} -h2 { - font-size: 135%; - margin-top: 1.5em; - margin-bottom: 14px; -} - -h1 { - border-bottom: 1px solid #879ECB; - font-size: 150%; - margin-top: 1.75em; - padding-bottom: 4px; -} - -h3 { - font-size: 120%; -} - -h1, h2, h3, h4, h5, h6 { - -webkit-transition: text-shadow 0.5s linear; - -moz-transition: text-shadow 0.5s linear; - -ms-transition: text-shadow 0.5s linear; - -o-transition: text-shadow 0.5s linear; - transition: text-shadow 0.5s linear; - margin-right: 15px; -} - -h1.glow, h2.glow, h3.glow, h4.glow, h5.glow, h6.glow { - text-shadow: 0 0 15px cyan; -} - -dt { - font-weight: bold; -} - -div.multicol { - -moz-column-gap: 1em; - -webkit-column-gap: 1em; - -moz-column-count: 3; - -webkit-column-count: 3; -} - -p.startli, p.startdd, p.starttd { - margin-top: 2px; -} - -p.endli { - margin-bottom: 0px; -} - -p.enddd { - margin-bottom: 4px; -} - -p.endtd { - margin-bottom: 2px; -} - -/* @end */ - -caption { - font-weight: bold; -} - -span.legend { - font-size: 70%; - text-align: center; -} - -h3.version { - font-size: 90%; - text-align: center; -} - -div.qindex, div.navtab{ - background-color: #EBEFF6; - border: 1px solid #A3B4D7; - text-align: center; -} - -div.qindex, div.navpath { - width: 100%; - line-height: 140%; -} - -div.navtab { - margin-right: 15px; -} - -/* @group Link Styling */ - -a { - color: #3D578C; - font-weight: normal; - text-decoration: none; -} - -.contents a:visited { - color: #4665A2; -} - -a:hover { - text-decoration: underline; -} - -a.qindex { - font-weight: bold; -} - -a.qindexHL { - font-weight: bold; - background-color: #9CAFD4; - color: #ffffff; - border: 1px double #869DCA; -} - -.contents a.qindexHL:visited { - color: #ffffff; -} - -a.el { - font-weight: bold; -} - -a.elRef { -} - -a.code, a.code:visited { - color: #4665A2; -} - -a.codeRef, a.codeRef:visited { - color: #4665A2; -} - -/* @end */ - -dl.el { - margin-left: -1cm; -} - -pre.fragment { - border: 1px solid #C4CFE5; - background-color: #FBFCFD; - padding: 4px 6px; - margin: 4px 8px 4px 2px; - overflow: auto; - word-wrap: break-word; - font-size: 9pt; - line-height: 125%; - font-family: monospace, fixed; - font-size: 105%; -} - -div.fragment { - padding: 4px; - margin: 4px; - background-color: #FBFCFD; - border: 1px solid #C4CFE5; -} - -div.line { - font-family: monospace, fixed; - font-size: 13px; - min-height: 13px; - line-height: 1.0; - text-wrap: unrestricted; - white-space: -moz-pre-wrap; /* Moz */ - white-space: -pre-wrap; /* Opera 4-6 */ - white-space: -o-pre-wrap; /* Opera 7 */ - white-space: pre-wrap; /* CSS3 */ - word-wrap: break-word; /* IE 5.5+ */ - text-indent: -53px; - padding-left: 53px; - padding-bottom: 0px; - margin: 0px; - -webkit-transition-property: background-color, box-shadow; - -webkit-transition-duration: 0.5s; - -moz-transition-property: background-color, box-shadow; - -moz-transition-duration: 0.5s; - -ms-transition-property: background-color, box-shadow; - -ms-transition-duration: 0.5s; - -o-transition-property: background-color, box-shadow; - -o-transition-duration: 0.5s; - transition-property: background-color, box-shadow; - transition-duration: 0.5s; -} - -div.line.glow { - background-color: cyan; - box-shadow: 0 0 10px cyan; -} - -span.lineno { - padding-right: 4px; - text-align: right; - border-right: 2px solid #0F0; - background-color: #E8E8E8; - white-space: pre; -} -span.lineno a { - background-color: #D8D8D8; -} - -span.lineno a:hover { - background-color: #C8C8C8; -} - -div.ah { - background-color: black; - font-weight: bold; - color: #ffffff; - margin-bottom: 3px; - margin-top: 3px; - padding: 0.2em; - border: solid thin #333; - border-radius: 0.5em; - -webkit-border-radius: .5em; - -moz-border-radius: .5em; - box-shadow: 2px 2px 3px #999; - -webkit-box-shadow: 2px 2px 3px #999; - -moz-box-shadow: rgba(0, 0, 0, 0.15) 2px 2px 2px; - background-image: -webkit-gradient(linear, left top, left bottom, from(#eee), to(#000),color-stop(0.3, #444)); - background-image: -moz-linear-gradient(center top, #eee 0%, #444 40%, #000); -} - -div.groupHeader { - margin-left: 16px; - margin-top: 12px; - font-weight: bold; -} - -div.groupText { - margin-left: 16px; - font-style: italic; -} - -body { - background-color: white; - color: black; - margin: 0; -} - -div.contents { - margin-top: 10px; - margin-left: 12px; - margin-right: 8px; -} - -td.indexkey { - background-color: #EBEFF6; - font-weight: bold; - border: 1px solid #C4CFE5; - margin: 2px 0px 2px 0; - padding: 2px 10px; - white-space: nowrap; - vertical-align: top; -} - -td.indexvalue { - background-color: #EBEFF6; - border: 1px solid #C4CFE5; - padding: 2px 10px; - margin: 2px 0px; -} - -tr.memlist { - background-color: #EEF1F7; -} - -p.formulaDsp { - text-align: center; -} - -img.formulaInl { - vertical-align: middle; -} - -div.center { - text-align: center; - margin-top: 0px; - margin-bottom: 0px; - padding: 0px; -} - -div.center img { - border: 0px; -} - -address.footer { - text-align: right; - padding-right: 12px; -} - -img.footer { - border: 0px; - vertical-align: middle; -} - -/* @group Code Colorization */ - -span.keyword { - color: #008000 -} - -span.keywordtype { - color: #604020 -} - -span.keywordflow { - color: #e08000 -} - -span.comment { - color: #800000 -} - -span.preprocessor { - color: #806020 -} - -span.stringliteral { - color: #002080 -} - -span.charliteral { - color: #008080 -} - -span.vhdldigit { - color: #ff00ff -} - -span.vhdlchar { - color: #000000 -} - -span.vhdlkeyword { - color: #700070 -} - -span.vhdllogic { - color: #ff0000 -} - -blockquote { - background-color: #F7F8FB; - border-left: 2px solid #9CAFD4; - margin: 0 24px 0 4px; - padding: 0 12px 0 16px; -} - -/* @end */ - -td.tiny { - font-size: 75%; -} - -.dirtab { - padding: 4px; - border-collapse: collapse; - border: 1px solid #A3B4D7; -} - -th.dirtab { - background: #EBEFF6; - font-weight: bold; -} - -hr { - height: 0px; - border: none; - border-top: 1px solid #4A6AAA; -} - -hr.footer { - height: 1px; -} - -/* @group Member Descriptions */ - -table.memberdecls { - border-spacing: 0px; - padding: 0px; -} - -.memberdecls td, .fieldtable tr { - -webkit-transition-property: background-color, box-shadow; - -webkit-transition-duration: 0.5s; - -moz-transition-property: background-color, box-shadow; - -moz-transition-duration: 0.5s; - -ms-transition-property: background-color, box-shadow; - -ms-transition-duration: 0.5s; - -o-transition-property: background-color, box-shadow; - -o-transition-duration: 0.5s; - transition-property: background-color, box-shadow; - transition-duration: 0.5s; -} - -.memberdecls td.glow, .fieldtable tr.glow { - background-color: cyan; - box-shadow: 0 0 15px cyan; -} - -.mdescLeft, .mdescRight, -.memItemLeft, .memItemRight, -.memTemplItemLeft, .memTemplItemRight, .memTemplParams { - background-color: #F9FAFC; - border: none; - margin: 4px; - padding: 1px 0 0 8px; -} - -.mdescLeft, .mdescRight { - padding: 0px 8px 4px 8px; - color: #555; -} - -.memItemLeft, .memItemRight, .memTemplParams { - border-bottom: 1px solid #DEE4F0; -} - -.memItemLeft, .memTemplItemLeft { - white-space: nowrap; -} - -.memItemRight { - width: 100%; -} - -.memTemplParams { - color: #4665A2; - white-space: nowrap; -} - -/* @end */ - -/* @group Member Details */ - -/* Styles for detailed member documentation */ - -.memtemplate { - font-size: 80%; - color: #4665A2; - font-weight: normal; - margin-left: 9px; -} - -.memnav { - background-color: #EBEFF6; - border: 1px solid #A3B4D7; - text-align: center; - margin: 2px; - margin-right: 15px; - padding: 2px; -} - -.mempage { - width: 100%; -} - -.memitem { - padding: 0; - margin-bottom: 10px; - margin-right: 5px; - -webkit-transition: box-shadow 0.5s linear; - -moz-transition: box-shadow 0.5s linear; - -ms-transition: box-shadow 0.5s linear; - -o-transition: box-shadow 0.5s linear; - transition: box-shadow 0.5s linear; - display: table !important; - width: 100%; -} - -.memitem.glow { - box-shadow: 0 0 15px cyan; -} - -.memname { - font-weight: bold; - margin-left: 6px; -} - -.memname td { - vertical-align: bottom; -} - -.memproto, dl.reflist dt { - border-top: 1px solid #A8B8D9; - border-left: 1px solid #A8B8D9; - border-right: 1px solid #A8B8D9; - padding: 6px 0px 6px 0px; - color: #253555; - font-weight: bold; - text-shadow: 0px 1px 1px rgba(255, 255, 255, 0.9); - background-image:url('nav_f.png'); - background-repeat:repeat-x; - background-color: #E2E8F2; - /* opera specific markup */ - box-shadow: 5px 5px 5px rgba(0, 0, 0, 0.15); - border-top-right-radius: 4px; - border-top-left-radius: 4px; - /* firefox specific markup */ - -moz-box-shadow: rgba(0, 0, 0, 0.15) 5px 5px 5px; - -moz-border-radius-topright: 4px; - -moz-border-radius-topleft: 4px; - /* webkit specific markup */ - -webkit-box-shadow: 5px 5px 5px rgba(0, 0, 0, 0.15); - -webkit-border-top-right-radius: 4px; - -webkit-border-top-left-radius: 4px; -} - -.memdoc, dl.reflist dd { - border-bottom: 1px solid #A8B8D9; - border-left: 1px solid #A8B8D9; - border-right: 1px solid #A8B8D9; - padding: 6px 10px 2px 10px; - background-color: #FBFCFD; - border-top-width: 0; - background-image:url('nav_g.png'); - background-repeat:repeat-x; - background-color: #FFFFFF; - /* opera specific markup */ - border-bottom-left-radius: 4px; - border-bottom-right-radius: 4px; - box-shadow: 5px 5px 5px rgba(0, 0, 0, 0.15); - /* firefox specific markup */ - -moz-border-radius-bottomleft: 4px; - -moz-border-radius-bottomright: 4px; - -moz-box-shadow: rgba(0, 0, 0, 0.15) 5px 5px 5px; - /* webkit specific markup */ - -webkit-border-bottom-left-radius: 4px; - -webkit-border-bottom-right-radius: 4px; - -webkit-box-shadow: 5px 5px 5px rgba(0, 0, 0, 0.15); -} - -dl.reflist dt { - padding: 5px; -} - -dl.reflist dd { - margin: 0px 0px 10px 0px; - padding: 5px; -} - -.paramkey { - text-align: right; -} - -.paramtype { - white-space: nowrap; -} - -.paramname { - color: #602020; - white-space: nowrap; -} -.paramname em { - font-style: normal; -} -.paramname code { - line-height: 14px; -} - -.params, .retval, .exception, .tparams { - margin-left: 0px; - padding-left: 0px; -} - -.params .paramname, .retval .paramname { - font-weight: bold; - vertical-align: top; -} - -.params .paramtype { - font-style: italic; - vertical-align: top; -} - -.params .paramdir { - font-family: "courier new",courier,monospace; - vertical-align: top; -} - -table.mlabels { - border-spacing: 0px; -} - -td.mlabels-left { - width: 100%; - padding: 0px; -} - -td.mlabels-right { - vertical-align: bottom; - padding: 0px; - white-space: nowrap; -} - -span.mlabels { - margin-left: 8px; -} - -span.mlabel { - background-color: #728DC1; - border-top:1px solid #5373B4; - border-left:1px solid #5373B4; - border-right:1px solid #C4CFE5; - border-bottom:1px solid #C4CFE5; - text-shadow: none; - color: white; - margin-right: 4px; - padding: 2px 3px; - border-radius: 3px; - font-size: 7pt; - white-space: nowrap; -} -/* @end */ - -/* these are for tree view when not used as main index */ - -div.directory { - margin: 10px 0px; - border-top: 1px solid #A8B8D9; - border-bottom: 1px solid #A8B8D9; - width: 100%; -} - -.directory table { - border-collapse:collapse; -} - -.directory td { - margin: 0px; - padding: 0px; - vertical-align: top; -} - -.directory td.entry { - white-space: nowrap; - padding-right: 6px; -} - -.directory td.entry a { - outline:none; -} - -.directory td.entry a img { - border: none; -} - -.directory td.desc { - width: 100%; - padding-left: 6px; - padding-right: 6px; - padding-top: 3px; - border-left: 1px solid rgba(0,0,0,0.05); -} - -.directory tr.even { - padding-left: 6px; - background-color: #F7F8FB; -} - -.directory img { - vertical-align: -30%; -} - -.directory .levels { - white-space: nowrap; - width: 100%; - text-align: right; - font-size: 9pt; -} - -.directory .levels span { - cursor: pointer; - padding-left: 2px; - padding-right: 2px; - color: #3D578C; -} - -div.dynheader { - margin-top: 8px; - -webkit-touch-callout: none; - -webkit-user-select: none; - -khtml-user-select: none; - -moz-user-select: none; - -ms-user-select: none; - user-select: none; -} - -address { - font-style: normal; - color: #2A3D61; -} - -table.doxtable { - border-collapse:collapse; - margin-top: 4px; - margin-bottom: 4px; -} - -table.doxtable td, table.doxtable th { - border: 1px solid #2D4068; - padding: 3px 7px 2px; -} - -table.doxtable th { - background-color: #374F7F; - color: #FFFFFF; - font-size: 110%; - padding-bottom: 4px; - padding-top: 5px; -} - -table.fieldtable { - width: 100%; - margin-bottom: 10px; - border: 1px solid #A8B8D9; - border-spacing: 0px; - -moz-border-radius: 4px; - -webkit-border-radius: 4px; - border-radius: 4px; - -moz-box-shadow: rgba(0, 0, 0, 0.15) 2px 2px 2px; - -webkit-box-shadow: 2px 2px 2px rgba(0, 0, 0, 0.15); - box-shadow: 2px 2px 2px rgba(0, 0, 0, 0.15); -} - -.fieldtable td, .fieldtable th { - padding: 3px 7px 2px; -} - -.fieldtable td.fieldtype, .fieldtable td.fieldname { - white-space: nowrap; - border-right: 1px solid #A8B8D9; - border-bottom: 1px solid #A8B8D9; - vertical-align: top; -} - -.fieldtable td.fielddoc { - border-bottom: 1px solid #A8B8D9; - width: 100%; -} - -.fieldtable tr:last-child td { - border-bottom: none; -} - -.fieldtable th { - background-image:url('nav_f.png'); - background-repeat:repeat-x; - background-color: #E2E8F2; - font-size: 90%; - color: #253555; - padding-bottom: 4px; - padding-top: 5px; - text-align:left; - -moz-border-radius-topleft: 4px; - -moz-border-radius-topright: 4px; - -webkit-border-top-left-radius: 4px; - -webkit-border-top-right-radius: 4px; - border-top-left-radius: 4px; - border-top-right-radius: 4px; - border-bottom: 1px solid #A8B8D9; -} - -.tabsearch { - top: 0px; - left: 10px; - height: 36px; - background-image: url('tab_b.png'); - z-index: 101; - overflow: hidden; - font-size: 13px; -} - -.navpath ul -{ - font-size: 11px; - background-image:url('tab_b.png'); - background-repeat:repeat-x; - height:30px; - line-height:30px; - color:#8AA0CC; - border:solid 1px #C2CDE4; - overflow:hidden; - margin:0px; - padding:0px; -} - -.navpath li -{ - list-style-type:none; - float:left; - padding-left:10px; - padding-right:15px; - background-image:url('bc_s.png'); - background-repeat:no-repeat; - background-position:right; - color:#364D7C; -} - -.navpath li.navelem a -{ - height:32px; - display:block; - text-decoration: none; - outline: none; - font-family: 'Lucida Grande',Geneva,Helvetica,Arial,sans-serif; -} - -.navpath li.navelem a:hover -{ - color:#6884BD; -} - -.navpath li.footer -{ - list-style-type:none; - float:right; - padding-left:10px; - padding-right:15px; - background-image:none; - background-repeat:no-repeat; - background-position:right; - color:#364D7C; - font-size: 8pt; -} - -div.summary -{ - float: right; - font-size: 8pt; - padding-right: 5px; - width: 50%; - text-align: right; -} - -div.summary a, div.ingroups a -{ - white-space: nowrap; -} - -div.ingroups -{ - font-size: 8pt; - width: 50%; - text-align: left; -} - -div.header -{ - background-image:url('nav_h.png'); - background-repeat:repeat-x; - background-color: #F9FAFC; - margin: 0px; - border-bottom: 1px solid #C4CFE5; -} - -div.headertitle -{ - padding: 5px 5px 5px 10px; -} - -dl -{ - padding: 0 0 0 10px; -} - -dl.section -{ - margin-left: 0px; - padding-left: 0px; -} - -dl.note -{ - margin-left:-7px; - padding-left: 3px; - border-left:4px solid; - border-color: #D0C000; -} - -dl.warning, dl.attention -{ - margin-left:-7px; - padding-left: 3px; - border-left:4px solid; - border-color: #FF0000; -} - -dl.pre, dl.post, dl.invariant -{ - margin-left:-7px; - padding-left: 3px; - border-left:4px solid; - border-color: #00D000; -} - -dl.deprecated -{ - margin-left:-7px; - padding-left: 3px; - border-left:4px solid; - border-color: #505050; -} - -dl.todo -{ - margin-left:-7px; - padding-left: 3px; - border-left:4px solid; - border-color: #00C0E0; -} - -dl.test -{ - margin-left:-7px; - padding-left: 3px; - border-left:4px solid; - border-color: #3030E0; -} - -dl.bug -{ - margin-left:-7px; - padding-left: 3px; - border-left:4px solid; - border-color: #C08050; -} - -dl.section dd { - margin-bottom: 6px; -} - -.image, .dotgraph, .mscgraph -{ - text-align: center; -} - -.caption -{ - font-weight: bold; -} - -div.zoom -{ - border: 1px solid #90A5CE; -} - -dl.citelist { - margin-bottom:50px; -} - -dl.citelist dt { - color:#334975; - float:left; - font-weight:bold; - margin-right:10px; - padding:5px; -} - -dl.citelist dd { - margin:2px 0; - padding:5px 0; -} - -div.toc { - padding: 14px 25px; - background-color: #F4F6FA; - border: 1px solid #D8DFEE; - border-radius: 7px 7px 7px 7px; - float: right; - height: auto; - margin: 0 20px 10px 10px; - width: 200px; -} - -div.toc li { - background: url("bdwn.png") no-repeat scroll 0 5px transparent; - font: 10px/1.2 Verdana,DejaVu Sans,Geneva,sans-serif; - margin-top: 5px; - padding-left: 10px; - padding-top: 2px; -} - -div.toc h3 { - font: bold 12px/1.2 Arial,FreeSans,sans-serif; - color: #4665A2; - border-bottom: 0 none; - margin: 0; -} - -div.toc ul { - list-style: none outside none; - border: medium none; - padding: 0px; -} - -div.toc li.level1 { - margin-left: 0px; -} - -div.toc li.level2 { - /*margin-left: 15px;*/ -} - -div.toc li.level3 { - /*margin-left: 30px;*/ -} - -div.toc li.level4 { - /*margin-left: 45px;*/ -} - -.inherit_header { - font-weight: bold; - color: gray; - cursor: pointer; - -webkit-touch-callout: none; - -webkit-user-select: none; - -khtml-user-select: none; - -moz-user-select: none; - -ms-user-select: none; - user-select: none; -} - -.inherit_header td { - padding: 6px 0px 2px 5px; -} - -.inherit { - display: none; -} - -tr.heading h2 { - margin-top: 12px; - margin-bottom: 4px; -} - -@media print -{ - #top { display: none; } - #side-nav { display: none; } - #nav-path { display: none; } - body { overflow:visible; } - h1, h2, h3, h4, h5, h6 { page-break-after: avoid; } - .summary { display: none; } - .memitem { page-break-inside: avoid; } - #doc-content - { - margin-left:0 !important; - height:auto !important; - width:auto !important; - overflow:inherit; - display:inline; - } -} - diff --git a/tools/cmake/DefinePackages.cmake b/tools/cmake/DefinePackages.cmake index 6b9449b499..718320030f 100644 --- a/tools/cmake/DefinePackages.cmake +++ b/tools/cmake/DefinePackages.cmake @@ -832,13 +832,9 @@ set(DOC_SOURCES doc/doxygen/FAQ.doc doc/doxygen/deployment.doc - doc/doxygen/footer.html - doc/doxygen/header.html - doc/doxygen/index.doc doc/doxygen/inside.doc doc/doxygen/inside_tests.doc doc/doxygen/inside_cmake.doc - doc/doxygen/inside_doxygen.doc doc/doxygen/inside_extending.doc doc/doxygen/inside_release.doc doc/doxygen/module-sd.doc @@ -849,11 +845,9 @@ set(DOC_SOURCES doc/doxygen/ns3.doc doc/doxygen/outcomes.doc doc/doxygen/outcomes_logs.doc - doc/doxygen/outcomes_MC.doc doc/doxygen/outcomes_vizu.doc doc/doxygen/platform.doc doc/doxygen/platform_lua.doc - doc/doxygen/stylesheet.css doc/doxygen/uhood.doc doc/doxygen/uhood_switch.doc doc/doxygen/uhood_arch.doc -- 2.20.1