+++ /dev/null
-/*! @page uhood_tech Coding Standard and Technical Considerations
-
-
-There is two main things you want to know about the internals of
-SimGrid. First, you need to understand the component organization, as
-SimGrid is heavily layered, with each level being rather highly
-specialized and optimized toward a task. For that, please head to
-@ref uhood_arch.
-
-Then, if you work actively on the SimGrid project, the second point
-you need to understand is about the infrastructure of the SimGrid
-project, ie how to extend the framework in any way, how the automatic
-tests are run, and so on. These informations are split on several
-pages, as follows:
-
- - @subpage inside_tests
- - @subpage inside_doxygen
- - @subpage inside_extending
- - @subpage inside_cmake
- - @subpage inside_release
-
-@section uhood_tech_config Insider's Configuration
-
-The default build configuration of SimGrid fits the user needs, but
-they are not adapted to the ones actually working on SimGrid. See @ref
-install_src_config for more information. Note that this is very
-different from runtime configuration.
-
-In particular, the build is configured by default to produce highly
-optimized binaries, at the price of high compilation time. The
-rational is that users will compile SimGrid only once, and use it many
-times. This is exactly the contrary for the insiders, so you want to
-turn off \b enable_compile_optimizations.
-
-Symmetrically, \b enable_compile_warnings is off for the users because
-we don't want to bother them with compiler warnings (that abort the
-build in SimGrid), but any insider must turn this option on, or your
-code will be refused from the main repository.
-
-@section uhood_tech_codstand Automatically Enforcing our Coding Standards
-
-If you plan to commit code to the SimGrid project, you definitely need
-to install the relevant tool to ensure that your changes follow our
-coding standards:
-
-@verbatim
-sudo apt-get install clang-format-3.8
-ln -s $PWD/tools/git-hooks/clang-format.pre-commit .git/hooks/pre-commit
-@endverbatim
-
-This will add an extra verification before integrating any commit that
-you could prepare. If your code does not respects our formating code,
-git will say so, and provide a ready to use patch that you can apply
-to improve your commit. Just carefully read the error message you get
-to find the exact command with git-apply to fix your formating.
-
-If you find that for a specific commit, the formatter does a very bad
-job, then add --no-verify to your git commit command line.
-
-@section uhood_tech_tricks Insider tricks
-
-Over the years, we accumulated a few tricks that make it easier to
-work with SimGrid. Here is a somewhat unsorted list of such tricks.
-
-### Easy testing
-
-Launching all tests can be very time consuming, so you want to build
-and run the tests in parallel. Also, you want to save the build output
-to disk, for further reference. This is exactly what the
-BuildSimGrid.sh script does. It is upper-cased so that the shell
-completion works and allow to run it in 4 key press: `./B<tab>`
-
-Note that if you build out of tree (as you should, see below), the
-script builds the build/default directory. I usually copy the file in
-each build/ subdir to test each of them separately.
-
-### Easy out of tree builds
-
-It is easy to break one build configuration or another. That's
-perfectly OK and we will not point fingers if it happens. But it is
-somewhat forbidden to leave the tree broken for a long while. Monitor
-the build daemons after you push something, and strive to fix any
-breakage ASAP.
-
-To easily switch between the configs without rebuilding everything,
-create a set of out of tree builds (as explained in @ref
-install_cmake_outsrc) in addition to your main build tree.
-To not mess with git, you want to put your build tree under the build/
-directory, which is ignored by git. For example, I have the following
-directories: build/clang build/java build/full
-(but YMMV).
-
-Then, the problem is that when you traverse these directories, you
-cannot edit the sources (that are in the srcdir, while you're in
-bindir). This makes it difficult to launch the tests and everything.
-
-To solve that issue, just call `make hardlinks` from your build dir.
-This will create hard links allowing to share every source files into
-the build dir. They are not copied, but hard linked. It means that
-each file is accessible under several names, from the srcdir and from
-the bindirs. If you edit a source file found under bindir, the srcdir
-version (visible to git) will also be changed (that's the same file,
-after all).
-
-Note that the links sometimes broken by git or others. Relaunching
-`make hardlinks` may help if you're getting incoherent build results.
-*/
