1 |
|
2 @c ======================================================================== |
|
3 @c Begin document body here |
|
4 @c ======================================================================== |
|
5 |
|
6 @c ======================================================================== |
|
7 @c PART: Getting Started |
|
8 @c ======================================================================== |
|
9 @c The below chapters are under the major heading "Getting Started" |
|
10 @c This is similar to the Latex \part command |
|
11 @c |
|
12 @c ======================================================================== |
|
13 @c Getting Started |
|
14 @c ======================================================================== |
|
15 @node Getting Started |
|
16 @chapter Getting Started |
|
17 |
|
18 @menu |
|
19 * Downloading ns-3:: |
|
20 * Building ns-3:: |
|
21 * Testing ns-3:: |
|
22 * Running a Script:: |
|
23 @end menu |
|
24 |
|
25 @c ======================================================================== |
|
26 @c Downloading ns-3 |
|
27 @c ======================================================================== |
|
28 |
|
29 @node Downloading ns-3 |
|
30 @section Downloading ns-3 |
|
31 |
|
32 @cindex Prerequisites |
|
33 @cindex Dependencies |
|
34 The @command{ns-3} system as a whole is a fairly complex system and has a |
|
35 number of dependencies on other components. Along with the systems you will |
|
36 most likely deal with every day (the GNU toolchain, Mercurial, you programmer |
|
37 editor) you will need to ensure that a number of additional libraries are |
|
38 present on your system before proceeding. @command{ns-3} provides a wiki |
|
39 for your reading pleasure that includes pages with many useful hints and tips. |
|
40 One such page is the ``Installation'' page, |
|
41 @uref{http://www.nsnam.org/wiki/index.php/Installation}. |
|
42 |
|
43 The ``Prerequisites'' section of this wiki page explains which packages are |
|
44 required to support common @command{ns-3} options, and also provides the |
|
45 commands used to install them for common Linux variants. Cygwin users will |
|
46 have to use the Cygwin installer (if you are a Cygwin user, you used it to |
|
47 install Cygwin). |
|
48 |
|
49 You may want to take this opportunity to explore the @command{ns-3} wiki |
|
50 a bit since there really is a wealth of information there. |
|
51 |
|
52 @cindex Linux |
|
53 @cindex Cygwin |
|
54 @cindex GNU |
|
55 @cindex toolchain |
|
56 @cindex Mercurial |
|
57 @cindex Waf |
|
58 From this point forward, we are going to assume that the reader is working in |
|
59 Linux or a Linux emulation environment (Linux, Cygwin, etc.) and has the GNU |
|
60 toolchain installed and verified along with the prerequisites mentioned |
|
61 above. We are also going to assume that you have Mercurial and Waf installed |
|
62 and running on the target system as described in the ``Getting Started'' section |
|
63 of the @command{ns-3} web site: |
|
64 @uref{http://www.nsnam.org/getting_started.html}. |
|
65 |
|
66 @cindex tarball |
|
67 The @command{ns-3} code is available in Mercurial repositories on the server |
|
68 @uref{http://code.nsnam.org}. You can also download a tarball release at |
|
69 @uref{http://www.nsnam.org/releases/}, or you can work with repositories |
|
70 using Mercurial. We recommend using Mercurial unless there's a good reason |
|
71 not to. See the end of this section for instructions on how to get a tarball |
|
72 release. |
|
73 |
|
74 @cindex repository |
|
75 The simplest way to get started using Mercurial repositories is to use the |
|
76 @code{ns-3-allinone} environment. This is a set of scripts that manages the |
|
77 downloading and building of various subsystems of @command{ns-3} for you. We |
|
78 recommend that you begin your @command{ns-3} adventures in this environment |
|
79 as it can really simplify your life at this point. |
|
80 |
|
81 @subsection Downloading ns-3 Using Mercurial |
|
82 One practice is to create a directory called @code{repos} in one's home |
|
83 directory under which one can keep local Mercurial repositories. |
|
84 @emph{Hint: we will assume you do this later in the tutorial.} If you adopt |
|
85 that approach, you can get a copy of @code{ns-3-allinone} by typing the |
|
86 following into your Linux shell (assuming you have installed Mercurial): |
|
87 |
|
88 @verbatim |
|
89 cd |
|
90 mkdir repos |
|
91 cd repos |
|
92 hg clone http://code.nsnam.org/ns-3-allinone |
|
93 @end verbatim |
|
94 |
|
95 As the hg (Mercurial) command executes, you should see something like the |
|
96 following displayed, |
|
97 |
|
98 @verbatim |
|
99 destination directory: ns-3-allinone |
|
100 requesting all changes |
|
101 adding changesets |
|
102 adding manifests |
|
103 adding file changes |
|
104 added 31 changesets with 45 changes to 7 files |
|
105 7 files updated, 0 files merged, 0 files removed, 0 files unresolved |
|
106 @end verbatim |
|
107 |
|
108 After the clone command completes, you should have a directory called |
|
109 @code{ns-3-allinone} under your @code{~/repos} directory, the contents of which should |
|
110 look something like the following: |
|
111 |
|
112 @verbatim |
|
113 build.py* constants.py dist.py* download.py* README util.py |
|
114 @end verbatim |
|
115 |
|
116 Notice that you really just downloaded some Python scripts. The next step |
|
117 will be to use those scripts to download and build the @command{ns-3} |
|
118 distribution of your choice. |
|
119 |
|
120 @cindex repository |
|
121 If you go to the following link: @uref{http://code.nsnam.org/}, |
|
122 you will see a number of repositories. Many are the private repositories of |
|
123 the @command{ns-3} development team. The repositories of interest to you will |
|
124 be prefixed with ``ns-3''. Official releases of @command{ns-3} will be |
|
125 numbered as @code{ns-3.<release>.<hotfix>}. For example, a second hotfix to a |
|
126 still hypothetical release nine of @command{ns-3} would be numbered as |
|
127 @code{ns-3.9.2}. |
|
128 |
|
129 The current development snapshot (unreleased) of @command{ns-3} may be found |
|
130 at @uref{http://code.nsnam.org/ns-3-dev/}. The |
|
131 developers attempt to keep these repository in consistent, working states but |
|
132 they are in a development area with unreleased code present, so you may want |
|
133 to consider staying with an official release if you do not need newly- |
|
134 introduced features. |
|
135 |
|
136 Since the release numbers are going to be changing, I will stick with |
|
137 the more constant ns-3-dev here in the tutorial, but you can replace the |
|
138 string ``ns-3-dev'' with your choice of release (e.g., ns-3.6) in the |
|
139 text below. You can find the latest version of the |
|
140 code either by inspection of the repository list or by going to the |
|
141 @uref{http://www.nsnam.org/getting_started.html,,``Getting Started''} |
|
142 web page and looking for the latest release identifier. |
|
143 |
|
144 Go ahead and change into the @code{ns-3-allinone} directory you created when |
|
145 you cloned that repository. We are now going to use the @code{download.py} |
|
146 script to pull down the various pieces of @command{ns-3} you will be using. |
|
147 |
|
148 Go ahead and type the following into your shell (remember you can substitute |
|
149 the name of your chosen release number instead of @code{ns-3-dev} -- like |
|
150 @code{"ns-3.6"} if you want to work with a |
|
151 stable release). |
|
152 |
|
153 @verbatim |
|
154 ./download.py -n ns-3-dev |
|
155 @end verbatim |
|
156 |
|
157 Note that the default for the @code{-n} option is @code{ns-3-dev} and so the |
|
158 above is actually redundant. We provide this example to illustrate how to |
|
159 specify alternate repositories. In order to download @code{ns-3-dev} you |
|
160 can actually use the defaults and simply type, |
|
161 |
|
162 @verbatim |
|
163 ./download.py |
|
164 @end verbatim |
|
165 |
|
166 As the hg (Mercurial) command executes, you should see something like the |
|
167 following, |
|
168 |
|
169 @verbatim |
|
170 # |
|
171 # Get NS-3 |
|
172 # |
|
173 |
|
174 Cloning ns-3 branch |
|
175 => hg clone http://code.nsnam.org/ns-3-dev ns-3-dev |
|
176 requesting all changes |
|
177 adding changesets |
|
178 adding manifests |
|
179 adding file changes |
|
180 added 4634 changesets with 16500 changes to 1762 files |
|
181 870 files updated, 0 files merged, 0 files removed, 0 files unresolved |
|
182 @end verbatim |
|
183 |
|
184 This is output by the download script as it fetches the actual @code{ns-3} |
|
185 code from the repository. |
|
186 |
|
187 The download script is smart enough to know that on some platforms various |
|
188 pieces of ns-3 are not supported. On your platform you may not see some |
|
189 of these pieces come down. However, on most platforms, the process should |
|
190 continue with something like, |
|
191 |
|
192 @verbatim |
|
193 # |
|
194 # Get PyBindGen |
|
195 # |
|
196 |
|
197 Required pybindgen version: 0.10.0.640 |
|
198 Trying to fetch pybindgen; this will fail if no network connection is available. Hit Ctrl-C to skip. |
|
199 => bzr checkout -rrevno:640 https://launchpad.net/pybindgen pybindgen |
|
200 Fetch was successful. |
|
201 @end verbatim |
|
202 |
|
203 This was the download script getting the Python bindings generator for you. |
|
204 Note that you will need bazaar (bzr), a version control system, to download |
|
205 PyBindGen. Next you should see (modulo platform variations) something along |
|
206 the lines of, |
|
207 |
|
208 @verbatim |
|
209 # |
|
210 # Get NSC |
|
211 # |
|
212 |
|
213 Required NSC version: nsc-0.5.0 |
|
214 Retrieving nsc from https://secure.wand.net.nz/mercurial/nsc |
|
215 => hg clone https://secure.wand.net.nz/mercurial/nsc nsc |
|
216 requesting all changes |
|
217 adding changesets |
|
218 adding manifests |
|
219 adding file changes |
|
220 added 273 changesets with 17565 changes to 15175 files |
|
221 10622 files updated, 0 files merged, 0 files removed, 0 files unresolved |
|
222 @end verbatim |
|
223 |
|
224 This part of the process is the script downloading the Network Simulation |
|
225 Cradle for you. Note that NSC is not supported on OSX or Cygwin and works |
|
226 best with gcc-3.4 or gcc-4.2 or greater series. |
|
227 |
|
228 After the download.py script completes, you should have several new directories |
|
229 under @code{~/repos/ns-3-allinone}: |
|
230 |
|
231 @verbatim |
|
232 build.py* constants.pyc download.py* nsc/ README util.pyc |
|
233 constants.py dist.py* ns-3-dev/ pybindgen/ util.py |
|
234 @end verbatim |
|
235 |
|
236 Go ahead and change into @code{ns-3-dev} under your @code{~/repos/ns-3-allinone} |
|
237 directory. You should see something like the following there: |
|
238 |
|
239 @verbatim |
|
240 AUTHORS examples/ RELEASE_NOTES utils/ wscript |
|
241 bindings/ LICENSE samples/ VERSION wutils.py |
|
242 CHANGES.html ns3/ scratch/ waf* |
|
243 doc/ README src/ waf.bat* |
|
244 @end verbatim |
|
245 |
|
246 You are now ready to build the @command{ns-3} distribution. |
|
247 |
|
248 @subsection Downloading ns-3 Using a Tarball |
|
249 The process for downloading @command{ns-3} via tarball is simpler than the |
|
250 Mercurial process since all of the pieces are pre-packaged for you. You just |
|
251 have to pick a release, download it and decompress it. |
|
252 |
|
253 As mentioned above, one practice is to create a directory called @code{repos} |
|
254 in one's home directory under which one can keep local Mercurial repositories. |
|
255 One could also keep a @code{tarballs} directory. @emph{Hint: the tutorial |
|
256 will assume you downloaded into a @code{repos} directory, so remember the |
|
257 placekeeper.} If you adopt the @code{tarballs} directory approach, you can |
|
258 get a copy of a release by typing the following into your Linux shell |
|
259 (substitute the appropriate version numbers, of course): |
|
260 |
|
261 @verbatim |
|
262 cd |
|
263 mkdir tarballs |
|
264 cd tarballs |
|
265 wget http://www.nsnam.org/releases/ns-allinone-3.6.tar.bz2 |
|
266 tar xjf ns-allinone-3.6.tar.bz2 |
|
267 @end verbatim |
|
268 |
|
269 If you change into the directory @code{ns-allinone-3.6} you should see a |
|
270 number of files: |
|
271 |
|
272 @verbatim |
|
273 build.py* ns-3.6/ pybindgen-0.12.0.700/ util.py |
|
274 constants.py nsc-0.5.1/ README |
|
275 @end verbatim |
|
276 |
|
277 You are now ready to build the @command{ns-3} distribution. |
|
278 |
|
279 @c ======================================================================== |
|
280 @c Building ns-3 |
|
281 @c ======================================================================== |
|
282 |
|
283 @node Building ns-3 |
|
284 @section Building ns-3 |
|
285 |
|
286 @subsection Building with build.py |
|
287 @cindex building with build.py |
|
288 The first time you build the @command{ns-3} project you should build using the |
|
289 @command{allinone} environment. This will get the project configured for you |
|
290 in the most commonly useful way. |
|
291 |
|
292 Change into the directory you created in the download section above. If you |
|
293 downloaded using Mercurial you should have a directory called |
|
294 @code{ns-3-allinone} under your @code{~/repos} directory. If you downloaded |
|
295 using a tarball you should have a directory called something like |
|
296 @code{ns-allinone-3.6} under your @code{~/tarballs} directory. Take a deep |
|
297 breath and type the following: |
|
298 |
|
299 @verbatim |
|
300 ./build.py |
|
301 @end verbatim |
|
302 |
|
303 You will see lots of typical compiler output messages displayed as the build |
|
304 script builds the various pieces you downloaded. Eventually you should see the |
|
305 following magic words: |
|
306 |
|
307 @verbatim |
|
308 Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' |
|
309 'build' finished successfully (2m30.586s) |
|
310 @end verbatim |
|
311 |
|
312 Once the project has built you can say goodbye to your old friends, the |
|
313 @code{ns-3-allinone} scripts. You got what you needed from them and will now |
|
314 interact directly with Waf and we do it in the @code{ns-3-dev} directory, |
|
315 not in the @code{ns-3-allinone} directory. Go ahead and change into the |
|
316 @code{ns-3-dev} directory (or the directory for the appropriate release you |
|
317 downloaded. |
|
318 |
|
319 @verbatim |
|
320 cd ns-3-dev |
|
321 @end verbatim |
|
322 |
|
323 @subsection Building with Waf |
|
324 @cindex building with Waf |
|
325 @cindex configuring Waf |
|
326 @cindex building debug version with Waf |
|
327 @cindex compiling with Waf |
|
328 @cindex unit tests with Waf |
|
329 We use Waf to configure and build the @command{ns-3} project. It's not |
|
330 strictly required at this point, but it will be valuable to take a slight |
|
331 detour and look at how to make changes to the configuration of the project. |
|
332 Probably the most useful configuration change you can make will be to |
|
333 build the optimized version of the code. By default you have configured |
|
334 your project to build the debug version. Let's tell the project to do |
|
335 make an optimized build. To explain to Waf that it should do optimized |
|
336 builds you will need to execute the following command, |
|
337 |
|
338 @verbatim |
|
339 ./waf -d optimized configure |
|
340 @end verbatim |
|
341 |
|
342 This runs Waf out of the local directory (which is provided as a convenience |
|
343 for you). As the build system checks for various dependencies you should see |
|
344 output that looks similar to the following, |
|
345 |
|
346 @verbatim |
|
347 Checking for program g++ : ok /usr/bin/g++ |
|
348 Checking for program cpp : ok /usr/bin/cpp |
|
349 Checking for program ar : ok /usr/bin/ar |
|
350 Checking for program ranlib : ok /usr/bin/ranlib |
|
351 Checking for g++ : ok |
|
352 Checking for program pkg-config : ok /usr/bin/pkg-config |
|
353 Checking for -Wno-error=deprecated-declarations support : yes |
|
354 Checking for -Wl,--soname=foo support : yes |
|
355 Checking for header stdlib.h : ok |
|
356 Checking for header signal.h : ok |
|
357 Checking for header pthread.h : ok |
|
358 Checking for high precision time implementation : 128-bit integer |
|
359 Checking for header stdint.h : ok |
|
360 Checking for header inttypes.h : ok |
|
361 Checking for header sys/inttypes.h : not found |
|
362 Checking for library rt : ok |
|
363 Checking for header netpacket/packet.h : ok |
|
364 Checking for pkg-config flags for GSL : ok |
|
365 Checking for header linux/if_tun.h : ok |
|
366 Checking for pkg-config flags for GTK_CONFIG_STORE : ok |
|
367 Checking for pkg-config flags for LIBXML2 : ok |
|
368 Checking for library sqlite3 : ok |
|
369 Checking for NSC location : ok ../nsc (guessed) |
|
370 Checking for library dl : ok |
|
371 Checking for NSC supported architecture x86_64 : ok |
|
372 Checking for program python : ok /usr/bin/python |
|
373 Checking for Python version >= 2.3 : ok 2.5.2 |
|
374 Checking for library python2.5 : ok |
|
375 Checking for program python2.5-config : ok /usr/bin/python2.5-config |
|
376 Checking for header Python.h : ok |
|
377 Checking for -fvisibility=hidden support : yes |
|
378 Checking for pybindgen location : ok ../pybindgen (guessed) |
|
379 Checking for Python module pybindgen : ok |
|
380 Checking for pybindgen version : ok 0.10.0.640 |
|
381 Checking for Python module pygccxml : ok |
|
382 Checking for pygccxml version : ok 0.9.5 |
|
383 Checking for program gccxml : ok /usr/local/bin/gccxml |
|
384 Checking for gccxml version : ok 0.9.0 |
|
385 Checking for program sudo : ok /usr/bin/sudo |
|
386 Checking for program hg : ok /usr/bin/hg |
|
387 Checking for program valgrind : ok /usr/bin/valgrind |
|
388 ---- Summary of optional NS-3 features: |
|
389 Threading Primitives : enabled |
|
390 Real Time Simulator : enabled |
|
391 Emulated Net Device : enabled |
|
392 GNU Scientific Library (GSL) : enabled |
|
393 Tap Bridge : enabled |
|
394 GtkConfigStore : enabled |
|
395 XmlIo : enabled |
|
396 SQlite stats data output : enabled |
|
397 Network Simulation Cradle : enabled |
|
398 Python Bindings : enabled |
|
399 Python API Scanning Support : enabled |
|
400 Use sudo to set suid bit : not enabled (option --enable-sudo not selected) |
|
401 Build examples and samples : enabled |
|
402 Static build : not enabled (option --enable-static not selected) |
|
403 'configure' finished successfully (2.870s) |
|
404 @end verbatim |
|
405 |
|
406 Note the last part of the above output. Some ns-3 options are not enabled by |
|
407 default or require support from the underlying system to work properly. |
|
408 For instance, to enable XmlTo, the library libxml-2.0 must be found on the |
|
409 system. If this library were not found, the corresponding @command{ns-3} feature |
|
410 would not be enabled and a message would be displayed. Note further that there is |
|
411 a feature to use the program @code{sudo} to set the suid bit of certain programs. |
|
412 This is not enabled by default and so this feature is reported as ``not enabled.'' |
|
413 |
|
414 Now go ahead and switch back to the debug build. |
|
415 |
|
416 @verbatim |
|
417 ./waf -d debug configure |
|
418 @end verbatim |
|
419 |
|
420 The build system is now configured and you can build the debug versions of |
|
421 the @command{ns-3} programs by simply typing, |
|
422 |
|
423 @verbatim |
|
424 ./waf |
|
425 @end verbatim |
|
426 |
|
427 Some waf commands are meaningful during the build phase and some commands are valid |
|
428 in the configuration phase. For example, if you wanted to use the emulation |
|
429 features of @command{ns-3} you might want to enable setting the suid bit using |
|
430 sudo as described above. This turns out to be a configuration-time command, and so |
|
431 you could reconfigure using the following command |
|
432 |
|
433 @verbatim |
|
434 ./waf -d debug --enable-sudo configure |
|
435 @end verbatim |
|
436 |
|
437 If you do this, waf will have run sudo to change the socket creator programs of the |
|
438 emulation code to run as root. There are many other configure- and build-time options |
|
439 available in waf. To explore these options, type: |
|
440 |
|
441 @verbatim |
|
442 ./waf --help |
|
443 @end verbatim |
|
444 |
|
445 We'll use some of the testing-related commands in the next section. |
|
446 |
|
447 Okay, sorry, I made you build the @command{ns-3} part of the system twice, |
|
448 but now you know how to change the configuration and build optimized code. |
|
449 |
|
450 @c ======================================================================== |
|
451 @c Testing ns-3 |
|
452 @c ======================================================================== |
|
453 |
|
454 @node Testing ns-3 |
|
455 @section Testing ns-3 |
|
456 |
|
457 @cindex unit tests |
|
458 You can run the unit tests of the @command{ns-3} distribution by running the |
|
459 ``./test.py -c core'' script, |
|
460 |
|
461 @verbatim |
|
462 ./test.py -c core |
|
463 @end verbatim |
|
464 |
|
465 These tests are run in parallel by waf. You should eventually |
|
466 see a report saying that, |
|
467 |
|
468 @verbatim |
|
469 47 of 47 tests passed (47 passed, 0 failed, 0 crashed, 0 valgrind errors) |
|
470 @end verbatim |
|
471 |
|
472 This is the important message. |
|
473 |
|
474 You will also see output from the test runner and the output will actually look something like, |
|
475 |
|
476 @verbatim |
|
477 Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' |
|
478 Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' |
|
479 'build' finished successfully (1.799s) |
|
480 PASS: TestSuite ns3-wifi-interference |
|
481 PASS: TestSuite histogram |
|
482 PASS: TestSuite sample |
|
483 PASS: TestSuite ipv4-address-helper |
|
484 PASS: TestSuite devices-wifi |
|
485 PASS: TestSuite propagation-loss-model |
|
486 |
|
487 ... |
|
488 |
|
489 PASS: TestSuite attributes |
|
490 PASS: TestSuite config |
|
491 PASS: TestSuite global-value |
|
492 PASS: TestSuite command-line |
|
493 PASS: TestSuite basic-random-number |
|
494 PASS: TestSuite object |
|
495 PASS: TestSuite random-number-generators |
|
496 47 of 47 tests passed (47 passed, 0 failed, 0 crashed, 0 valgrind errors) |
|
497 @end verbatim |
|
498 |
|
499 This command is typically run by @code{users} to quickly verify that an |
|
500 @command{ns-3} distribution has built correctly. |
|
501 |
|
502 @c ======================================================================== |
|
503 @c Running a Script |
|
504 @c ======================================================================== |
|
505 |
|
506 @node Running a Script |
|
507 @section Running a Script |
|
508 @cindex running a script with Waf |
|
509 We typically run scripts under the control of Waf. This allows the build |
|
510 system to ensure that the shared library paths are set correctly and that |
|
511 the libraries are available at run time. To run a program, simply use the |
|
512 @code{--run} option in Waf. Let's run the @command{ns-3} equivalent of the |
|
513 ubiquitous hello world program by typing the following: |
|
514 |
|
515 @verbatim |
|
516 ./waf --run hello-simulator |
|
517 @end verbatim |
|
518 |
|
519 Waf first checks to make sure that the program is built correctly and |
|
520 executes a build if required. Waf then executes the program, which |
|
521 produces the following output. |
|
522 |
|
523 @verbatim |
|
524 Hello Simulator |
|
525 @end verbatim |
|
526 |
|
527 @emph{Congratulations. You are now an ns-3 user.} |
|
528 |
|
529 @emph{What do I do if I don't see the output?} |
|
530 |
|
531 If you don't see @code{waf} messages indicating that the build was |
|
532 completed successfully, but do not see the ``Hello Simulator'' output, |
|
533 chances are that you have switched your build mode to ``optimized'' in |
|
534 the ``Building with Waf'' section, but have missed the change back to |
|
535 ``debug'' mode. All of the console output used in this tutorial uses a |
|
536 special @command{ns-3} logging component that is useful for printing |
|
537 user messages to the console. Output from this component is |
|
538 automatically disabled when you compile optimized code -- it is |
|
539 ``optimized out.'' If you don't see the ``Hello Simulator'' output, |
|
540 type the following, |
|
541 |
|
542 @verbatim |
|
543 ./waf -d debug configure |
|
544 @end verbatim |
|
545 |
|
546 to tell @code{waf} to build the debug versions of the @command{ns-3} |
|
547 programs. You must still build the actual debug version of the code by |
|
548 typing, |
|
549 |
|
550 @verbatim |
|
551 ./waf |
|
552 @end verbatim |
|
553 |
|
554 Now, if you run the @code{hello-simulator} program, you should see the |
|
555 expected output. |
|
556 |
|
557 If you want to run programs under another tool such as gdb or valgrind, |
|
558 see this @uref{http://www.nsnam.org/wiki/index.php/User_FAQ#How_to_run_NS-3_programs_under_another_tool,,wiki entry}. |
|
559 |
|