1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
|
/*! @page uhood_tech Coding Standard and Technical Considerations
This page describes the software infrastructure behind the SimGrid
project. This is not the components' organisation (described in @ref
uhood_arch) but informations on how to extend the framework, how the
automatic tests are run, and so on. These informations are split on
several pages, as follows:
- @ref uhood_tech_inside
- @subpage inside_tests
- @subpage inside_doxygen
- @subpage inside_extending
- @subpage inside_cmake
- @subpage inside_release
@section uhood_tech_inside Insiders Considerations
@subsection uhood_tech_inside_config Extra 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
rationale 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.
@verbatim
cmake -Denable_compile_optimizations=OFF \
-Denable_compile_warnings=ON .
@endverbatim
@subsection uhood_tech_inside_commit Interacting with git
During the Gran Refactoring to SimGrid4, things are evolving rather
quickly, and some changes impact a large amount of files. You should
thus not have long-standing branches, because they will rot very
quickly and you will suffer to merge them back. Instead, you should
work as much as possible with incremental changes that do not break
things, and get them directly in master.
Your commit message should follow the git habits, explained in this
<a href="http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html">blog
post</a>, or in the
<a href="https://github.com/atom/atom/blob/master/CONTRIBUTING.md#git-commit-messages">
git styleguide of Atom</a>.
@subsection uhood_tech_inside_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
# install clang-format
sudo apt-get install clang-format-3.9 # debian
# tell git to call the script on each commit
ln -s $(realpath 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.
@subsection uhood_tech_tricks Random 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 allows one 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 more than one working
day. 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.
### Unsorted hints
* If you want to debug memory allocation problems, here are a few hints:
- disable compiler optimizations, to have better backtraces;
- disable the mallocators, or it will be hard to match malloc's with free's;
- disable model checking, unless your problem lies in the model
checker part of SimGrid (MC brings its own malloc implementation,
which valgrind does not really love).
All this is configured with:
cmake -Denable_model-checking=OFF
-Denable_mallocators=OFF
-Denable_compile_optimizations=OFF .
* If you break the logs, you want to define XBT_LOG_MAYDAY at the
beginning of log.h. It deactivates the whole logging mechanism,
switching to printfs instead. SimGrid becomes incredibly verbose
when doing so, but it you let you fixing things.
*/
|
