Podręcznik do symulatora sieci ns-3. Rozdział 3

rozdziały 1,2

3 Rozpoczęcie pracy
3.1 Przegląd
3.2 Wymagania wstępne
3.2.1 Pobieranie wersji ns-3 w postaci archiwum źródłowego
3.3 Pobieranie ns-3 za pomocą Git
3.3.1 Pobieranie ns-3 za pomocą Bake
3.4 Kompilacja ns-3
3.4.1 Kompilacja za pomocą build.py
3.4.2 Kompilacja za pomocą Bake
3.4.3 Kompilacja za pomocą Waf
3.5 Testowanie ns-3
3.6 Uruchamianie skryptu
3.6.1 Argumenty wiersza poleceń
3.6.2 Debugowanie
3.6.3 Katalog roboczy

Rozdział 3

Rozpoczęcie pracy

Rozdział ten ma na celu przygotowanie czytelnika do pracy z komputerem, na którym być może nigdy nie był zainstalowany ns-3. Wprowadzenie obejmuje obsługiwane platformy, wymagania wstępne, metody uzyskiwania ns-3, metody kompilacji ns-3 oraz sposoby weryfikacji kompilacji i uruchamiania prostych programów.

3.1 Przegląd

Symulator ns-3 został zbudowany jako system współpracujących bibliotek programowych. Podczas kompilacji kod programów użytkownika jest linkowany z tymi bibliotekami. Do pisania programów użytkownika używa się języków programowania C++ lub Python.

Ns-3 jest dystrybuowany w postaci kodu źródłowego, co oznacza, że docelowy system musi mieć środowisko programistyczne, aby najpierw skompilować biblioteki, a następnie zbudować program użytkownika. W zasadzie ns-3 może być dystrybuowany jako gotowe biblioteki dla określonego systemu, i w przyszłości mogą być dystrybuowane w ten sposób. Jednak obecnie wielu użytkowników faktycznie wykonuje swoją pracę, edytując sam ns-3, dlatego przydatne jest posiadanie kodu źródłowego do kompilacji bibliotek. Jeśli ktoś chciałby podjąć się pracy nad tworzeniem gotowych bibliotek i pakietów dla systemów operacyjnych, proszę skontaktować się z listą dyskusyjną. ns-developers.

Następnie omówimy trzy sposoby pobierania i kompilacji ns-3. Pierwszym jest pobranie i zbudowanie oficjalnej wersji z głównej strony. Drugim jest pobranie i skompilowanie deweloperskich wersji podstawowej instalacji ns-3. Trzecim jest użycie dodatkowych narzędzi do budowy w celu pobrania większej liczby rozszerzeń dla ns-3. Przejdziemy przez każdy z nich, ponieważ narzędzia różnią się nieco.

Z doświadczeniem użytkownicy systemu Linux mogą się zastanawiać, dlaczego ns‑3 nie jest dostarczany jako pakiet, jak większość innych bibliotek korzystających z menedżera pakietów. Mimo że istnieją pakiety binarne dla różnych dystrybucji systemu Linux (np. Debian), większość użytkowników ostatecznie edytuje biblioteki i musi samodzielnie kompilować ns‑3, dlatego dostępność kodu źródłowego jest wygodna. Z tego powodu skupimy się na instalacji z kodu źródłowego.

Dla większości zastosowań ns‑3 prawa root nie są wymagane, zaleca się używanie nieuprzywilejowanego konta użytkownika.

3.2 Wymagania wstępne

Cały zestaw dostępnych bibliotek ns‑3 ma szereg zależności od bibliotek zewnętrznych, ale w większości ns‑3 może być skompilowany i używany z wsparciem dla kilku popularnych (często instalowanych domyślnie) komponentów: kompilator C++, Python, edytor kodu źródłowego (np. vim, emacs lub Eclipse) oraz, jeśli używane są repozytoria deweloperskie, systemy kontroli wersji Git. Większość początkujących użytkowników nie musi się martwić, jeśli ich konfiguracja raportuje o pewnych brakujących dodatkowych funkcjach ns‑3, ale dla tych, którzy pragną pełnej instalacji, projekt ma wiki, która zawiera strony z wieloma przydatnymi wskazówkami i poradami. Jedną z takich stron jest strona "Instalacja" z instrukcjami dotyczącymi instalacji dla różnych systemów, dostępnych pod tym adresem: https://www.nsnam.org/wiki/Installation.

Sekcja „Wymagania wstępne” tej strony wiki wyjaśnia, jakie pakiety są wymagane do wsparcia ogólnych opcji ns‑3 i dostarcza komendy używane do ich instalacji w popularnych wersjach Linux lub macOS.

Możesz skorzystać z możliwości zapoznania się z wiki ns‑3 lub główną stroną internetową: https://www.nsnam.org, ponieważ tam znajduje się wiele informacji. Zaczynając od ostatniej wersji ns‑3 (ns‑3.29), do uruchomienia ns‑3 wymagane są następujące narzędzia:

Narzędzie Pakiet/wersja

• Kompilator C++
  clang++ lub g++ (g++ wersja 4.9 lub wyższa)
• Python
  python2 wersja >= 2.7.10 lub python3 wersja >= 3.4
• Gitem
  jakakolwiek najnowsza wersja (do uzyskania dostępu do ns‑3 na GitLab.com)
• tar
  jakakolwiek najnowsza wersja (do rozpakowania wydania ns‑3)
• bunzip2
  jakakolwiek najnowsza wersja (do rozpakowania wydania ns‑3)

Aby sprawdzić wersję Pythona zainstalowaną domyślnie, wpisz python -VAby sprawdzić wersję g++, wpisz g++ -v. Jeśli jakieś narzędzia są nieobecne lub zbyt stare, zapoznaj się z instrukcją instalacji na stronie wiki ns-3.

Od tego momentu zakładamy, że czytelnik pracuje w Linuxie, MacOS lub emulatorze środowiska Linux i ma przynajmniej wymienione wcześniej narzędzia.

3.2.1 Pobieranie wersji ns-3 w postaci archiwum źródłowego

To jest sposób działania nowego użytkownika, który chce pobrać i eksperymentować z najnowszymi wersjami wydania i pakietu ns-3. Wydania ns-3 publikowane są w postaci skompresowanych archiwów źródłowych, czasami nazywanych tarball. tarball — to specjalny format archiwum programowego, w którym wiele plików jest łączonych w jeden. Archiwum zazwyczaj jest skompresowane. Proces pobierania ns-3 przez tarball jest prosty, wystarczy wybrać wydanie, pobrać je i rozpakować.

Zakładając, że jako użytkownik chcesz skompilować ns-3 w lokalnym katalogu o nazwie workspace, możesz uzyskać roboczą kopię wydania, wpisując w konsoli Linux następujące komendy (oczywiście zastępując odpowiednie numery wersji)

$ cd 
$ mkdir workspace 
$ cd workspace 
$ wget https://www.nsnam.org/release/ns-allinone-3.29.tar.bz2 
$ tar xjf ns-allinone-3.29.tar.bz2 

Zauważ używaną powyżej narzędzie . Wersje ICU są nieistotne., które jest narzędziem wiersza poleceń do pobierania obiektów z Internetu. Jeśli go nie zainstalowałeś, możesz użyć do tego przeglądarki.

Podążając tymi krokami, przejdziesz do katalogu ns-allinone-3.29, gdzie powinieneś zobaczyć kilka plików i katalogów

$ cd ns-allinone-3.29
$ ls
bake constants.py ns-3.29 README
build.py netanim-3.108 pybindgen-0.17.0.post58+ngcf00cc0 util.py

Teraz jesteś gotów skompilować podstawową dystrybucję ns-3 i możesz przejść do sekcji dotyczącej kompilacji ns-3.

3.3 Pobieranie ns-3 za pomocą Git

Kod ns-3 jest dostępny w repozytoriach Git na GitLab.com pod adresem https://gitlab.com/nsnam/. Grupa nsnam łączy różne repozytoria używane przez projekt z otwartym kodem źródłowym.

Najprostszym sposobem rozpoczęcia korzystania z repozytoriów Git jest zrobienie forka lub sklonowanie środowiska ns-3-allinone. To zestaw skryptów, który zarządza pobieraniem i kompilowaniem najczęściej używanych podsystemów ns-3. Jeśli jesteś nowy w Git, terminy 'fork' i 'klonowanie' mogą być ci obce; jeśli tak, zalecamy po prostu sklonowanie (stwórz swoją własną kopię) repozytorium znajdującego się na GitLab.com w ten sposób:

$ cd 
$ mkdir workspace 
$ cd workspace 
$ git clone https://gitlab.com/nsnam/ns-3-allinone.git 
$ cd ns-3-allinone 

Na tym etapie widok twojego katalogu ns-3-allinone nieco różni się od opisanej powyżej lokalizacji archiwum wydania. Powinna wyglądać mniej więcej tak:

$ ls
build.py constants.py download.py README util.py

Zwróć uwagę na obecność skryptu download.py, który dodatkowo wyodrębni ns-3 oraz towarzyszący kod źródłowy. Tutaj masz do wyboru: możesz pobrać najnowszy zrzut rozwoju ns-3:

$ python download.py

lub preferować wydanie ns-3, używając flagi -n do określenia numeru wydania:

$ python download.py -n ns-3.29

Po tym kroku dodatkowe repozytoria ns-3-allinone zostaną pobrane do katalogu ns-3, bake, pybindgen i netanim.

Uwaga
Na maszynie z czystym Ubuntu 16.04 musiałem zmienić polecenie na następujące: $ sudo python3 download.py -n ns-3.29 (tutaj i dalej uwagi tłumacza).

3.3.1 Pobieranie ns-3 za pomocą Bake

Dwie wspomniane metody (archiwum kodu źródłowego lub repozytorium ns-3-allinone przez Git) są przydatne do uzyskania najprostszej instalacji ns-3 z wieloma dodatkami (pybindgen do generowania powiązań Python i netanim do animacji sieci). Trzecie repozytorium, dostarczane domyślnie w ns-3-allinone, nazywa się bake.

Bake — jest to narzędzie do skoordynowanej kompilacji oprogramowania z kilku repozytoriów, zaprojektowane dla projektu ns-3. Bake może być używane do uzyskania deweloperskich wersji ns-3, a także do pobierania i kompilacji rozszerzeń podstawowej wersji dystrybucji ns-3, takich jak środowisko Direct Code Execution, CradleNetwork Simulation Cradle, możliwość tworzenia nowych powiązań Python oraz różne "aplikacje" ns-3.

Uwaga
CradleNetwork Simulation Cradle — jest to framework, który pozwala na użycie rzeczywistych stosów sieciowych TCP/IP wewnątrz symulatora sieciowego.

Jeśli przewidujesz, że Twoja instalacja ns-3 powinna mieć rozwinięte lub dodatkowe funkcje, możesz podążać tą ścieżką instalacji.

W ostatnich wersjach ns-3 Bake został dodany w tar-wydaniu. Do wydania dołączono plik konfiguracyjny, który pozwala pobierać wersje oprogramowania aktualne na moment tworzenia wydania. To znaczy, na przykład, że wersja Bake, która jest dystrybuowana z wydaniem ns-3.29, może być używana do uzyskiwania komponentów dla tego wydania ns-3 lub wcześniejszych, ale nie może być używana do wyodrębniania komponentów dla późniejszych wydań (jeśli plik opisu pakietu bakeconf.xml nie został zaktualizowany).

Możesz również uzyskać najnowszą kopię bake, wpisując następujące polecenie w swoim terminalu Linux (pod warunkiem, że masz zainstalowanego Gita):

$ cd 
$ mkdir workspace 
$ cd workspace 
$ git clone https://gitlab.com/nsnam/bake.git

Podczas wykonywania polecenia git powinieneś zobaczyć coś takiego:

Klonowanie do 'bake'...
remote: Obliczanie obiektów: 2086, zakończone.
remote: Liczenie obiektów: 100% (2086/2086), zakończone.
remote: Kompresowanie obiektów: 100% (649/649), zakończone.
remote: Łącznie 2086 (delta 1404), ponownie użyto 2078 (delta 1399)
Odbieranie obiektów: 100% (2086/2086), 2.68 MiB | 3.82 MiB/s, zakończone.
Rozwiązywanie delt: 100% (1404/1404), zakończone.

Po zakończeniu polecenia clone powinieneś mieć katalog o nazwie bake, którego zawartość powinna wyglądać mniej więcej tak:

$ cd bake
$ ls
bake bakeconf.xml bake.py doc examples generate-binary.py test TODO

Zauważ, że pobrałeś kilka skryptów Pythona oraz moduł Pythona o nazwie bake i plik konfiguracyjny XML. Następnym krokiem będzie użycie tych skryptów do pobrania i zbudowania dystrybucji ns-3, którą wybierzesz. Dostępne są różne cele konfiguracji:

1. ns-3.29: moduł odpowiadający wersji wydania; pobierze komponenty podobne do wydania w archiwum tar;

2. ns-3-dev: podobny moduł, ale z użyciem kodu z gałęzi deweloperskiej;

3. ns-allinone-3.29: moduł, który zawiera inne dodatkowe funkcje, takie jak routowanie Click oraz Network Simulation Cradle, Openflow dla ns-3.

4. ns-3-allinone: podobnie jak wersja wydania modułu allinone, ale dla kodu deweloperskiego.

Uwaga
Click — modułowa architektura oprogramowania do tworzenia routerów.

Openflow — protokół zarządzania procesem przetwarzania danych przesyłanych w sieci przez routery i przełączniki, realizujący technologię sieci programowo-konfigurowanej.

Aktualny zrzut rozwoju (niewydany) ns-3 można znaleźć pod adresem:https://gitlab.com/nsnam/ns-3-dev.git.

Deweloperzy starają się utrzymać te repozytoria w spójnym stanie roboczym, ale znajdują się one w fazie rozwoju i zawierają kod niewydany, dlatego jeśli nie planujesz korzystać z nowych funkcji, wybierz oficjalne wydanie.

Możesz znaleźć najnowszą wersję kodu, przeglądając listę repozytoriów lub przechodząc na stronę "ns-3 Releases":https://www.nsnam.org/releases/ i klikając link do najnowszej wersji. W tym przykładzie kontynuujemy z ns-3.29.

Teraz, aby uzyskać potrzebne nam składniki ns-3, użyjemy narzędzia Bake. Powiedzmy trochę o tym, jak działa Bake.

Bake działa, pobierając źródła pakietów do katalogu source i instalując biblioteki w katalogu budowania. Bake można uruchomić, wskazując na plik binarny, ale jeśli chcesz uruchamiać Bake nie z katalogu, do którego został przeniesiony, warto dodać ścieżkę do bake twojej ścieżki (zmienna środowiskowa PATH), na przykład w następujący sposób (przykład dla powłoki Linux bash). Przejdź do katalogu „bake”, a następnie ustaw następujące zmienne środowiskowe:

$ export BAKE_HOME=`pwd` 
$ export PATH=$PATH:$BAKE_HOME:$BAKE_HOME/build/bin 
$ export PYTHONPATH=$PYTHONPATH:$BAKE_HOME:$BAKE_HOME/build/lib

To umieści program bake.py w ścieżce powłoki, co pozwoli innym programom znajdować pliki wykonywalne i biblioteki stworzone przez bake. W niektórych przypadkach użycia bake, opisana powyżej konfiguracja PATH i PYTHONPATH nie jest wymagana, ale dla pełnej kompilacji ns‑3-allinone (z dodatkowymi pakietami) zwykle jest potrzebna.

Wejdź do katalogu roboczego i wpisz w konsoli następujące:

$ ./bake.py configure -e ns-3.29

Następnie poprosimy Bake o sprawdzenie, czy mamy wystarczająco narzędzi do pobrania różnych komponentów. Wpisz:

$ ./bake.py check

Powinieneś zobaczyć coś takiego jak:

> Python - OK 
> Kompilator GNU C++ - OK 
> Mercurial - OK 
> Git - OK 
> Narzędzie Tar - OK 
> Narzędzie do rozpakowywania - OK 
> Make - OK 
> cMake - OK 
> Narzędzie patch - OK 
> Szukana ścieżka narzędzi: /usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin ...

Szczególnie ważne są narzędzia do pobierania, takie jak Mercurial, CVS, Git i Bazaar, ponieważ pozwalają nam uzyskać kod. Na tym etapie zainstaluj brakujące narzędzia w sposób typowy dla twojego systemu (jeśli umiesz) lub poproś o pomoc swojego administratora systemu.

Następnie spróbuj pobrać oprogramowanie:

$ ./bake.py download

wynikiem powinno być coś takiego jak:

>> Szukam zależności systemowych setuptools - OK 
>> Szukam zależności systemowych libgoocanvas2 - OK 
>> Szukam zależności systemowych gi-cairo - OK 
>> Szukam zależności systemowych pygobject - OK 
>> Szukam zależności systemowych pygraphviz - OK 
>> Szukam zależności systemowych python-dev - OK 
>> Szukam zależności systemowych qt - OK 
>> Szukam zależności systemowych g++ - OK 
>> Pobieram pybindgen-0.19.0.post4+ng823d8b2 (katalog docelowy: pybindgen) - OK 
>> Pobieram netanim-3.108 - OK 
>> Pobieram ns-3.29 - OK

To oznacza, że pobrano trzy źródła. Teraz przejdź do katalogu source i wpisz ls; powinieneś zobaczyć:

$ cd source 
$ ls
netanim-3.108 ns-3.29 pybindgen

Teraz jesteś gotowy, aby zbudować dystrybucję ns‑3.

3.4 Kompilacja ns-3

Podobnie jak w przypadku pobierania ns‑3, jest kilka sposobów na zbudowanie ns‑3. Najważniejsze, co chcemy podkreślić, to że ns‑3 jest budowany za pomocą narzędzia do budowy, zwanego Waf, opisanego poniżej. Większość użytkowników będzie pracować z Waf, ale istnieje kilka przydatnych skryptów, które pomogą Ci rozpocząć lub zorganizować bardziej złożone zestawienia. Dlatego zanim przeczytasz o Waf, spójrz na build.py i zestawieniu z bake.

3.4.1 Kompilacja za pomocą build.py

Uwaga! Ten krok budowy jest dostępny tylko z wersji archiwum źródłowego, uzyskanej w sposób opisany powyżej; a nie pobranej przez git lub bake.

Pracując z archiwum wydania tarball, w ns‑3‑allinone jest dostępny przydatny skrypt, który może uprościć budowę komponentów. Nazywa się build.py. Ten program dostosuje projekt do Ciebie w najbardziej użyteczny sposób. Należy jednak pamiętać, że bardziej złożone konfiguracje i praca z ns‑3 zwykle obejmują użycie własnego systemu budowy ns‑3, Waf, który zostanie przedstawiony później w tym przewodniku.

Jeśli pobrałeś za pomocą tarball, to w Twoim katalogu ~\/workspace powinien pojawić się katalog o nazwie coś w rodzaju ns-allinone-3.29. Wpisz następujące polecenie:

$ .\/build.py --enable-examples --enable-tests

Przy wywołaniu build.py zastosowaliśmy argumenty wiersza poleceń, aby zbudować przykłady i testy używane w tym przewodniku, które w ns‑3 domyślnie nie są budowane. Domyślnie program również buduje wszystkie dostępne moduły. Następnie, jeśli chcesz, możesz zbudować ns‑3 bez przykładów i testów lub wykluczyć moduły, które nie są potrzebne do Twojej pracy.

Zobaczysz wiele komunikatów o wyjściu kompilatora, wyświetlanych przez skrypt podczas budowy różnych załadowanych przez Ciebie części. Najpierw skrypt spróbuje zbudować animatora netanim, następnie generator powiązań pybindgen i na końcu ns‑3. Po zakończeniu procesu powinieneś zobaczyć następujące:

Waf: Leaving directory '\/path\/to\/workspace\/ns-allinone-3.29\/ns-3.29\/build'\n'build' finished successfully (6m25.032s) \n\nModules built:\nantenna                aodv                     applications\nbrige                 buildings                config-store\ncore                   csma                     csma-layout\ndsdv                   dsr                      energy \nfd-net-device          flow-monitor             internet\ninternet-apps          lr-wpan                  lte\nmesh                   mobility                 mpi\nnetanim (no Python)    network                  nix-vector-routing \nolsr                   point-to-point           point-to-point-layout \npropagation            sixlowpan                spectrum \nstats                  tap-bridge               test (no Python) \ntopology-read          traffic-control          uan \nvirtual-net-device     visualizer               wave \nwifi                   wimax \n\nModules not built (see ns-3 tutorial for explanation):\nbrite                  click                    openflow \nLeaving directory .\/ns-3.29

W ostatnich trzech linijkach listingów widzimy komunikat o modułach, które nie zostały zbudowane:

Modules not built (see ns-3 tutorial for explanation):\nbrite                     click

To tylko oznacza, że niektóre moduły ns-3, które zależą od zewnętrznych bibliotek, mogły nie zostać skompilowane lub że ich kompilacja nie jest wymagana dla tej konfiguracji. To nie oznacza, że symulator się nie skompilował lub skompilowane moduły będą działały nieprawidłowo.

3.4.2 Kompilacja za pomocą Bake

Jeśli powyżej do pobrania kodu źródłowego z repozytoriów projektu użyłeś bakes, możesz kontynuować jego użycie do kompilacji ns-3. Wpisz:

$ ./bake.py build

i powinieneś zobaczyć coś takiego:

>> Budowanie pybindgen-0.19.0.post4+ng823d8b2 - OK 
>> Budowanie netanim-3.108 - OK 
>> Budowanie ns-3.29 - OK

Wskazówka.: możesz również wykonać oba kroki jednocześnie, ładując i kompilując, wywołując „bake.py deploy”.

Podczas kompilacji wszystkich komponentów mogą wystąpić błędy, ale kompilacja będzie kontynuowana, jeśli komponent nie jest obowiązkowy. Na przykład, niedawny problem z przenośnością polegał na tym, że castxml może być kompilowany przez narzędzie bake nie na wszystkich platformach. W takim przypadku może pojawić się komunikat typu:

>> Budowanie castxml - Problem 
> Problem: Opcjonalna zależność, moduł "castxml" nie powiódł się
Może to ograniczyć funkcjonalność finalnej kompilacji.
Jednak bake będzie kontynuować, ponieważ "castxml" nie jest istotną zależnością.
Więcej informacji można uzyskać, wywołując bake z opcją -v lub -vvv, aby uzyskać pełny tryb szczegółowy.

Jednak castxml jest wymagany tylko wtedy, gdy chcesz stworzyć zaktualizowane powiązania Pythona. Dla większości użytkowników nie ma takiej potrzeby (przynajmniej do czasu, gdy nie zaczną zmieniać ns-3), więc takie ostrzeżenia można na razie bezpiecznie zignorować.

Jeśli wystąpi błąd, następne polecenie da ci wskazówki dotyczące brakujących zależności:

$ ./bake.py show

Zostaną wymienione różne zależności pakietów, które próbujesz skompilować.

3.4.3 Kompilacja za pomocą Waf

Do tego momentu, aby rozpocząć kompilację ns-3, użyliśmy albo skryptu build.py, albo narzędzia bake. Te narzędzia są przydatne do kompilacji ns-3 i utrzymania bibliotek. W rzeczywistości uruchamiają narzędzie kompilacji Waf z katalogu ns-3. Waf jest dystrybuowane razem z kodem źródłowym ns-3. Większość użytkowników do konfiguracji i kompilacji ns-3 szybko przechodzi do bezpośredniego użycia Waf. Więc aby kontynuować, proszę przejść do katalogu ns-3, który początkowo utworzyłeś.

Obecnie nie jest to ściśle wymagane, ale warto zrobić małe wprowadzenie i przyjrzeć się, jak wprowadzać zmiany w konfiguracji projektu. Prawdopodobnie najważniejszą zmianą konfiguracji, którą możesz wprowadzić, będzie stworzenie zoptymalizowanej wersji kodu. Domyślnie ustawiłeś swój projekt na budowanie wersji debug. Przyjrzyjmy się projektowi, aby stworzyć zoptymalizowaną wersję. Aby wyjaśnić Waf, że ma wykonać zoptymalizowane kompilacje, w tym przykłady i testy, musisz wykonać następujące polecenia:

$ ./waf clean 
$ ./waf configure --build-profile=optimized --enable-examples --enable-tests

To uruchomi Waf poza lokalnym katalogiem (dla Twojej wygody). Pierwsze polecenie wykonuje czyszczenie poprzedniej kompilacji, które zazwyczaj nie jest ściśle konieczne, ale jest dobrym zwyczajem (zobacz także profile budowania poniżej); usunie wcześniej utworzone biblioteki i pliki obiektowe znajdujące się w katalogu build/. Kiedy projekt zostanie przekonfigurowany, a system budowania sprawdzi różne zależności, powinieneś zobaczyć wynik podobny do poniższego:

Ustawianie top na      : /home/ns3user/workspace/bake/source/ns-3-dev
Ustawianie out na      : /home/ns3user/workspace/bake/source/ns-3-dev/build
Sprawdzanie 'gcc' (kompilator C)        : /usr/bin/gcc 
Sprawdzanie wersji cc                : 7.3.0 
Sprawdzanie 'g++' (kompilator C++)      : /usr/bin/g++ 
Sprawdzanie flagi kompilacji -march=native support : ok 
Sprawdzanie flagi kompilacji -Wl,--soname=foo support : ok 
Sprawdzanie flagi kompilacji -std=c++11 support       : ok 
Sprawdzanie, czy header boost jest dostępny   : nagłówki nie znalezione, proszę, podaj argument --boost-includes (zobacz pomoc) 
Sprawdzanie, czy header boost jest dostępny   : nagłówki nie znalezione, proszę, podaj argument --boost-includes (zobacz pomoc) 
Sprawdzanie programu 'python'            : /usr/bin/python 
Sprawdzanie wersji pythona >= 2.3       : 2.7.15 python-config                                                                     : /usr/bin/python-config
Proszę o flagi pyembed '--cflags --libs --ldflags' : tak
Testowanie konfiguracji pyembed                                      : tak
Proszę o flagi pyext '--cflags --libs --ldflags'   : tak
Testowanie konfiguracji pyext                                        : tak

Sprawdzanie flagi kompilacji -fvisibility=hidden support          : ok 
Sprawdzanie flagi kompilacji -Wno-array-bounds support            : ok 
Sprawdzanie lokalizacji pybindgen          : ../pybindgen ,!(zgadnięte) 
Sprawdzanie modułu pythona 'pybindgen'   : 0.19.0. ,!post4+g823d8b2 
Sprawdzanie wersji pybindgen           : 0.19.0. ,!post4+g823d8b2 
Sprawdzanie fragmentu kodu                : tak 
Sprawdzanie dla typów uint64_t i unsigned long ekwiwalentność : nie 
Sprawdzanie fragmentu kodu                                 : nie 
Sprawdzanie dla typów uint64_t i unsigned long long ekwiwalentność     : tak 
Sprawdzanie dla apidef, które mogą być używane dla powiązań Pythona                       : gcc-LP64 
Sprawdzanie wewnętrznego GCC cxxabi         : zakończone 
Sprawdzanie modułu pythona 'pygccxml'    : nie znaleziono 
Sprawdzanie lokalizacji click              : nie znaleziono 
Sprawdzanie programu 'pkg-config'        : /usr/bin/pkg- ,!config 
Sprawdzanie 'gtk+-3.0'                  : nie znaleziono 
Sprawdzanie 'libxml-2.0'                : tak 
sprawdzanie uint128_t                   : nie znaleziono 
sprawdzanie __uint128_t                 : tak 
Sprawdzanie implementacji o wysokiej precyzji   : 128-bitowa liczba całkowita ,!(domyślna) 
Sprawdzanie nagłówka stdint.h             : tak 
Sprawdzanie nagłówka inttypes.h           : tak 
Sprawdzanie nagłówka sys/inttypes.h       : nie znaleziono 
Sprawdzanie nagłówka sys/types.h          : tak 
Sprawdzanie nagłówka sys/stat.h           : tak 
Sprawdzanie nagłówka dirent.h             : tak 
Sprawdzanie nagłówka stdlib.h             : tak 
Sprawdzanie nagłówka signal.h             : tak 
Sprawdzanie nagłówka pthread.h            : tak 
Sprawdzanie nagłówka stdint.h             : tak 
Sprawdzanie nagłówka inttypes.h           : tak 
Sprawdzanie nagłówka sys/inttypes.h       : nie znaleziono
Sprawdzanie biblioteki rt                  : tak 
Sprawdzanie nagłówka sys/ioctl.h          : tak 
Sprawdzanie nagłówka net/if.h             : tak 
Sprawdzanie nagłówka net/ethernet.h       : tak 
Sprawdzanie nagłówka linux/if_tun.h       : tak 
Sprawdzanie nagłówka netpacket/packet.h   : tak 
Sprawdzanie lokalizacji NSC                : nie znaleziono 
Sprawdzanie 'sqlite3'                   : nie znaleziono 
Sprawdzanie nagłówka linux/if_tun.h       : tak 
Sprawdzanie modułu pythona 'gi'          : 3.26.1 
Sprawdzanie modułu pythona 'gi.repository.GObject'      : ok 
Sprawdzanie modułu pythona 'cairo'                      : ok 
Sprawdzanie modułu pythona 'pygraphviz'                 : 1.4rc1 
Sprawdzanie modułu pythona 'gi.repository.Gtk'          : ok 
Sprawdzanie modułu pythona 'gi.repository.Gdk'          : ok 
Sprawdzanie modułu pythona 'gi.repository.Pango'        : ok 
Sprawdzanie modułu pythona 'gi.repository.GooCanvas'    : ok 
Sprawdzanie programu 'sudo'                             : /usr/bin/sudo 
Sprawdzanie programu 'valgrind'                         : nie znaleziono 
Sprawdzanie 'gsl' : nie znaleziono python-config            : nie znaleziono 
Sprawdzanie flagi kompilacji -fstrict-aliasing support : ok 
Sprawdzanie flagi kompilacji -fstrict-aliasing support : ok 
Sprawdzanie flagi kompilacji -Wstrict-aliasing support : ok 
Sprawdzanie flagi kompilacji -Wstrict-aliasing support : ok 
Sprawdzanie programu 'doxygen'                          : /usr/bin/doxygen
---- Podsumowanie opcjonalnych funkcji ns-3:
Profil budowy : zoptymalizowany
Katalog budowy : 
Integracja BRITE : nie włączona (BRITE nie włączone (zobacz opcję --with-,!brite)) 
Zbieranie metryk DES : nie włączone (domyślnie wyłączone) 
Emulacja FdNetDevice        : włączona 
Przykłady                     : włączone 
NetDevice deskryptor pliku    : włączony 
Biblioteka GNU Scientific (GSL) : nie włączona (GSL nie znaleziono) 
Biblioteka Gcrypt               : nie włączona
(nie znaleziono libgcrypt: możesz użyć ,!libgcrypt-config, aby znaleźć jej lokalizację.) GtkConfigStore               : nie włączona (biblioteka 'gtk+-3.0 >= 3.0' nie znaleziono)
Wspieranie MPI                  : nie włączone (opcja --enable-mpi nie wybrana)
Integracja ns-3 Click       : nie włączona (nsclick nie włączone (zobacz opcję --with-,!nsclick))
Integracja ns-3 OpenFlow   : nie włączona (Wymagane biblioteki boost nie znalezione) 
Kolebka Symulacji Sieciowej    : nie włączona (NSC nie znaleziono (zobacz opcję --with-nsc))
PlanetLab FdNetDevice         : nie włączona (system operacyjny PlanetLab nie wykryty ,!(zobacz opcję --force-planetlab)) Wizualizator PyViz : włączony 
Wsparcie skanowania API Pythona   : nie włączone (Brak modułu Pythona 'pygccxml')
Powiązania Pythona : włączone 
Symulator Czasu Rzeczywistego           : włączony 
Dane wyjściowe statystyk SQlite      : nie włączone (biblioteka 'sqlite3' nie znaleziona)
Most Tap                    : włączony 
FdNetDevice Tap               : włączony
Testy                         : włączone 
Primitives wątkowe          : włączone 
Użyj sudo, aby ustawić bit suid   : nie włączone (opcja --enable-sudo nie wybrana)
XmlIo                         : włączony
'configure' zakończone pomyślnie (6.387s)

Zwróć uwagę na ostatnią część powyższego wpisu. Niektóre opcje ns‑3 nie są włączone domyślnie lub wymagają wsparcia ze strony systemu, aby działały poprawnie. Na przykład, aby włączyć XmlTo, potrzebna jest biblioteka libxml-2.0. Jeśli ta biblioteka nie została znaleziona, a odpowiednia funkcja ns‑3 nie byłaby włączona, wyświetlony zostanie komunikat. Zauważ także, że istnieje możliwość użycia polecenia sudo do ustawienia bitu suid 'ustawienie ID grupy podczas uruchamiania' dla niektórych programów. Domyślnie nie jest on włączony, dlatego ta funkcja jest wyświetlana jako 'nie włączona' ('not enabled'). Wreszcie, aby uzyskać listę włączonych opcji, użyj Waf z parametrem --check-config.

Teraz wróćmy i przełączmy się z powrotem na wersję debug, która zawiera przykłady i testy.

$ ./waf clean 
$ ./waf configure --build-profile=debug --enable-examples --enable-tests

System budowy jest teraz skonfigurowany, a ty możesz zbudować wersje debugowania programów ns‑3, po prostu wpisując:

$ ./waf

Niech opisane powyżej kroki zmusiły cię do dwukrotnego zbudowania części systemu ns‑3, ale teraz wiesz, jak zmienić konfigurację i zbudować zoptymalizowany kod.

Aby sprawdzić, jaki profil jest aktywny dla danej konfiguracji projektu, istnieje polecenie:

$ ./waf --check-profile 
Waf: Wchodzę do katalogu `/path/to/ns-3-allinone/ns-3.29/build` 
Profil budowy: debug

Omówiony powyżej scenariusz build.py obsługuje także argumenty --enable-examples i --enable-tests, ale innych opcji Waf nie obsługuje bezpośrednio. Na przykład, to nie zadziała:

$ ./build.py --disable-python

reakcja będzie taka:

build.py: error: no such option: --disable-python

Jednak specjalny operator - - może być używany do przesyłania dodatkowych parametrów przez waf, więc zamiast wspomnianego powyżej zadziała następujące polecenie:

$ ./build.py -- --disable-python

ponieważ generuje podstawowe polecenie ./waf configure --disable-python. Oto kilka dodatkowych wskazówek dotyczących Waf.

Obsługa błędów kompilacji

Wydania ns-3 były testowane na najnowszych kompilatorach C++, dostępnych w momencie wydania na popularnych dystrybucjach Linux i MacOS. Jednak z biegiem czasu pojawiają się nowe dystrybucje z nowymi kompilatorami, które zazwyczaj są bardziej wymagające w kwestii ostrzeżeń. ns-3 konfiguruje swoją kompilację tak, aby traktować wszystkie ostrzeżenia jak błędy, dlatego czasami, jeśli korzystasz z starszej wersji w nowszym systemie, ostrzeżenie kompilatora może zatrzymać kompilację.

Na przykład, wcześniej wydano ns-3.28 dla Fedora 28, która zawierała nową główną wersję gcc (gcc-8). Kompilacja wydania ns-3.28 lub starszych wersji pod Fedora 28, z zainstalowanym Gtk2+, może spowodować taki błąd:

/usr/include/gtk-2.0/gtk/gtkfilechooserbutton.h:59:8: error: unnecessary parentheses ,!in declaration of ‘__gtk_reserved1’ [-Werror=parentheses] void (*__gtk_reserved1);

W wydaniach, począwszy od ns-3.28.1, dostępna jest opcja rozwiązania tych problemów. Wyłącza ona ustawienie flagi „-Werror” w g++ i clang++. Jest to opcja „—disable-werror”, która powinna być stosowana podczas konfigurowania: Waf $ ./waf configure --disable-werror --enable-examples --enable-tests

Konfiguracja lub kompilacja

Niektóre polecenia mają sens tylko w fazie konfiguracji, a niektóre działają tylko w fazie kompilacji. Na przykład, jeśli chcesz korzystać z funkcji emulacji ns-3, możesz włączyć ustawienie bitu

suid Waf , jak opisano powyżej. Anuluje to polecenia etapu konfiguracji, dzięki czemu możesz zmienić konfigurację, używając następującego polecenia, które również uwzględnia przykłady i testy. $ ./waf configure --enable-sudo --enable-examples --enable-tests używając sudoJeśli to zrobisz,

uruchomi

, aby zmienić programy tworzenia gniazd kodu emulacji do uruchamiania z uprawnieniami Waf dostępnych jest wiele innych opcji dla etapów konfiguracji i kompilacji. Aby zapoznać się z możliwościami, wpisz: sudo$ ./waf --help root. W Waf W następnej sekcji użyjemy niektórych opcji związanych z testowaniem.

Profile budowy

Już widzieliśmy, jak można skonfigurować

dla kompilacji

optimized Waf $ ./waf --build-profile=debug debug i Istnieje również pośredni profil budowy,:

jest synonimem

--build-profile release. Opcja -d . Profil budowy zarządza wykorzystaniem rejestrowania, asercji i kluczy optymalizacji kompilatora: --profil-budowy. Profil budowy zarządza używaniem logowania, stwierdzeń (assertions) oraz kluczy optymalizacji kompilatora:

Jak widać, rejestrowanie i asercje są dostępne tylko w wersjach debugujących. Zaleca się rozwijanie skryptu w trybie debugowania, a następnie wykonywanie powtórnych biegów (dla statystyk lub zmiany parametrów) w zoptymalizowanym profilu kompilacji.

Jeśli masz kod, który ma być wykonywany tylko w określonych profilach kompilacji, użyj makra Code Wrapper Macro:

NS_BUILD_DEBUG (std::cout << "Część linii wyjściowej..." << std::flush; timer.Start ,!()); DoLongInvolvedComputation ();
NS_BUILD_DEBUG (timer.Stop (); std::cout << "Zrobione: " << timer << std::endl;)

Domyślnie, Waf umieszcza artefakty budowy w katalogu budowy. Możesz określić inny katalog wyjściowy za pomocą opcji - -out, na przykład:

$ ./waf configure --out=my-build-dir

Łącząc to z profilami budowy, możesz łatwo przełączać się między różnymi parametrami kompilacji:

$ ./waf configure --build-profile=debug --out=build/debug
$ ./waf build
... 
$ ./waf configure --build-profile=optimized --out=build/optimized 
$ ./waf build
...

Co pozwala na pracę z wieloma kompilacjami, bez konieczności ciągłego przepisywania ostatniej kompilacji. Kiedy przełączasz się na inny profil, Waf będzie kompilować tylko ten, bez pełnej rekompilacji wszystkiego.

Kiedy w ten sposób przełączasz profile budowy, musisz zadbać o to, aby każdorazowo podawać te same parametry konfiguracji. Uniknięcie błędów pomoże w zdefiniowaniu kilku zmiennych środowiskowych:

$ export NS3CONFIG="--enable-examples --enable-tests" 
$ export NS3DEBUG="--build-profile=debug --out=build/debug"
$ export NS3OPT="--build-profile=optimized --out=build/optimized" 

$ ./waf configure $NS3CONFIG $NS3DEBUG
$ ./waf build 
... 
$ ./waf configure $NS3CONFIG $NS3OPT
$ ./waf build

Kompilatory i flagi

W podanych powyżej przykładach Waf do budowy ns-3 używa kompilatora C++ z GCC ( g++). Można jednak zmienić używany Waf kompilator C++, definiując zmienną środowiskową CXX. Na przykład, aby użyć kompilatora C++ Clang, clang++,

$ CXX="clang++" ./waf configure 
$ ./waf build 

Podobnie można skonfigurować Waf do używania rozproszonej kompilacji za pomocą distcc:

$ CXX="distcc g++" ./waf configure 
$ ./waf build

Bardziej szczegółowe informacje na temat distcc i rozproszonej kompilacji można znaleźć na stronie projektu w sekcji „Dokumentacja”. Aby podczas konfigurowania ns-3 dodać flagi kompilatora, użyj zmiennej środowiskowej CXXFLAGS_EXTRA.

Instalacja

Waf może być używana do instalacji bibliotek w różnych miejscach systemu. Domyślnie zbudowane biblioteki i pliki wykonywalne znajdują się w katalogu build, a ponieważ Waf zna lokalizację tych bibliotek i plików wykonywalnych, nie ma potrzeby instalowania bibliotek gdzie indziej.

Jeśli użytkownicy preferują instalację poza katalogiem budowy, mogą wykonać polecenie .\/waf install. Domyślnie prefiksem dla instalacji jest /usr/local, więc .\/waf install będzie instalował programy w /usr/local/bin, biblioteki w /usr/local/lib i pliki nagłówkowe w /usr/local/include. Uprawnienia superużytkownika są zazwyczaj wymagane do instalacji z domyślnym prefiksem, dlatego typowe polecenie będzie brzmiało sudo .\/waf install. Przy uruchomieniu Waf najpierw spróbuje użyć wspólnych bibliotek w katalogu budowy, a następnie będzie szukać bibliotek w ścieżce do bibliotek ustawionej w lokalnym otoczeniu. Dlatego podczas instalacji bibliotek w systemie dobrą praktyką jest sprawdzenie, czy używane są właściwe biblioteki. Użytkownicy mogą wybrać instalację z innym prefiksem, przekazując podczas konfiguracji opcję --prefix, na przykład:

.\/waf configure --prefix=\/opt\/local

Jeśli później, po zbudowaniu, użytkownik wpisze polecenie instalacji .\/waf, będzie użyty prefiks /opt/local.

Zespół .\/waf clean powinno być używane przed ponownym ustawieniem projektu, jeśli do instalacji będzie używany Waf z innym prefiksem.

W ten sposób, aby korzystać z ns‑3, nie ma potrzeby wywoływania .\/waf install. Większość użytkowników nie będzie potrzebować tej komendy, ponieważ Waf złapie aktualne biblioteki z katalogu budowy, ale niektórzy użytkownicy mogą uznać to za przydatne, jeśli ich działania obejmują pracę z programami poza katalogiem ns‑3.

Waf jest jednolity

Na najwyższym poziomie drzewa źródłowego ns‑3 istnieje tylko jeden skrypt Waf. Zaczynając pracę, spędzisz dużo czasu w katalogu scratch\/ lub głębiej, wsrc\/... i w tym czasie może być konieczne uruchomienie Waf. Możesz po prostu pamiętać, gdzie jesteś, i uruchomić Waf w następujący sposób:

$ ..\/..\/..\/waf ...

, ale to będzie nużące i podatne na błędy, dlatego istnieją lepsze rozwiązania. Jednym z powszechnych sposobów jest użycie edytora tekstu, takiego jak emacs lub vim, w którym otwierane są dwie sesje terminalowe, jedna używana do budowy ns‑3, a druga do edytowania kodu źródłowego. Jeśli masz tylko tarball, może pomóc zmienna środowiskowa:

$ export NS3DIR="$PWD" 
$ function waff { cd $NS3DIR && .\/waf $* ; } 

$ cd scratch 
$ waff build

W katalogu modułu może być kuszące dodanie trywialnego skryptu waf jako wzór exec ..\/..\/waf. Proszę, nie rób tego. To wprowadza w błąd nowicjuszy, a przy złej realizacji prowadzi do trudnych do wykrycia błędów kompilacji. Rozwiązania przedstawione powyżej to droga, którą należy podążać.

3.5 Testowanie ns-3

Możesz wykonać testy modułowe dystrybucji ns‑3, uruchamiając skrypt .\/test.py:

$ .\/test.py

Te testy są wykonywane równolegle z Waf. Ostatecznie powinieneś zobaczyć komunikat, że

92 z 92 testów przeszło (92 zaliczone, 0 niezaliczone, 0 zawiodło, 0 błędów valgrind)

To ważny komunikat do wykrywania awarii, zawieszeń lub błędów valgrind, wskazuje na problemy z kodem lub niekompatybilność między narzędziami a kodem.

Zobaczysz również końcowy wynik z Waf i testera wykonującego każdy test, który będzie wyglądać mniej więcej tak:

Waf: Wchodzenie do katalogu `\/path\/to\/workspace\/ns-3-allinone\/ns-3-dev\/build' 
Waf: Opuszczanie katalogu `\/path\/to\/workspace\/ns-3-allinone\/ns-3-dev\/build' 
'build' zakończone pomyślnie (1.799s) 

Zbudowane moduły:
aodv           applications          bridge
click          config-store          core
csma           csma-layout           dsdv
emu            energy                flow-monitor
internet       lte                   mesh
mobility       mpi                   netanim
network        nix-vector-routing    ns3tcp
ns3wifi        olsr                  openflow
point-to-point point-to-point-layout propagation
spectrum       stats                 tap-bridge
template       test                  tools
topology-read  uan                   virtual-net-device
visualizer     wifi                  wimax

PASS: TestSuite ns3-wifi-interference
PASS: TestSuite histogram 

...

PASS: TestSuite object
PASS: TestSuite random-number-generators
92 z 92 testów przeszło (92 zaliczone, 0 niezaliczone, 0 zawiodło, 0 błędów valgrind)

Ta komenda zwykle jest uruchamiana przez użytkowników w celu szybkiej weryfikacji poprawności budowy dystrybucji ns‑3. (Zauważ, że kolejność wierszy „PASS: ...” może się różnić, co jest w porządku. Ważne jest, aby w końcowej linii raportu wszystkie testy przeszły; żaden test nie zakończył się niepowodzeniem ani nie zawiódł.) I Waf, i test.py będą rozdzielać pracę po dostępnych rdzeniach procesora maszyny.

3.6 Uruchamianie skryptu

Zwykle uruchamiamy skrypty pod kontrolą Waf. Pozwala to systemowi budowania zagwarantować, że ścieżki do wspólnej biblioteki są ustawione poprawnie i biblioteki są dostępne w czasie wykonywania. Aby uruchomić program, po prostu użyj Waf z parametrem - run. Uruchomimy dla ns‑3 odpowiednik powszechnego programu hello world, wpisując następujące:

$ .\/waf --run hello-simulator

Waf najpierw sprawdzi, czy program został poprawnie zbudowany, a w razie potrzeby wykona budowę. Następnie Waf wykona program, który wygeneruje następujący wynik.

Hello Simulator

Gratulacje! Teraz jesteś użytkownikiem ns‑3!

Co zrobić, jeśli nie widzę wyników?

Jeśli widzisz komunikaty Waf, wskazujące, że budowanie zostało pomyślnie zakończone, ale nie widzisz wyników «Hello Simulator», istnieje prawdopodobieństwo, że w sekcji [Budowanie z Waf] przełączyłeś tryb budowy na Istnieje również pośredni profil budowy,, ale nie wykonałeś powrotnego przełączenia do trybu debug. Cały wynik konsoli używany w tym przewodniku wykorzystuje specjalny komponent ns‑3, który wykonuje zapis logów i został zastosowany do drukowania komunikatów użytkownika w konsoli. Wyjście z tego komponentu jest automatycznie wyłączone podczas kompilacji kodu zoptymalizowanego — jest "optymalizowane". Jeśli nie widzisz wyniku „Hello Simulator”, wpisz następujące polecenie:

$ .\/waf configure --build-profile=debug --enable-examples --enable-tests

aby skonfigurować Waf budowę wersji debugowych programów ns‑3, które zawierają przykłady i testy. Następnie musisz ponownie zbudować aktualną wersję debugową kodu, wpisując

$ ./waf

Teraz, jeśli uruchomisz program hello-simulator, powinieneś zobaczyć oczekiwany wynik.

3.6.1 Argumenty wiersza poleceń

Aby przekazać argumenty wiersza poleceń do programu ns‑3, użyj takiego szablonu:

$ .\/waf --run  --command-template="%s "

Zastąp nazwą swojego programu oraz argumentami. Argument - -command-template do Waf to w zasadzie przepis na stworzenie rzeczywistej linii poleceń Waf używanej do wykonania programu. Waf sprawdza, czy budowanie zostało zakończone, ustawia ścieżki do wspólnej biblioteki, a następnie, używając dostarczonego szablonu linii poleceń i podstawiając nazwę programu zamiast symbolu zastępczego %s, wywołuje plik wykonywalny. Jeśli ten składnik wydaje się skomplikowany, istnieje prostsza wersja, która obejmuje program ns‑3 i jego argumenty, ujęte w pojedyncze cudzysłowy:

$ .\/waf --run ' --arg1=value1 --arg2=value2 ...'

Innym, szczególnie przydatnym, przykładem jest wybiórcze uruchamianie zestawów testowych. Załóżmy, że istnieje zestaw testowy (suite) mytest (w rzeczywistości go nie ma). Wcześniej użyliśmy skryptu .\/test.py do równoległego uruchamiania całej serii testów, który wielokrotnie wywołuje program testowy test-runner. Wywołanie test-runner bezpośrednio do wykonania jednego testu:

$ ./waf --run test-runner --command-template="%s --suite=mytest --verbose"

Argumenty będą przekazane do programu test-runner. Ponieważ mytest nie istnieje, zostanie wygenerowana wiadomość o błędzie. Aby wydrukować dostępne opcje test-runnera, wpisz:

$ ./waf --run test-runner --command-template="%s --help"

3.6.2 Debugowanie

Aby uruchomić programy ns-3 pod kontrolą innego narzędzia, takiego jak debugger (na przykład gdb) lub narzędzie do sprawdzania pamięci (na przykład valgrind), użyj podobnej formy - -command-template = "…". Na przykład, aby uruchomić debuggerem gdb twój program hello-simulator ns-3 z argumentami:

$ ./waf --run=hello-simulator --command-template="gdb %s --args "

Zauważ, że nazwa programu ns-3 jest podawana z argumentem - run, a narzędzie zarządzające (tutaj gdb) jest pierwszym tokenem w argumencie - -command-template. Opcja - -args donosi gdb, co oznacza, że pozostała część linii poleceń należy do „niższego” programu. (Niektóre wersje gdb nie rozumieją opcji - -args. W takim przypadku usuń argumenty programu z - -command-template i użyj zestawu poleceń gdb args.) Możemy połączyć ten przepis z poprzednim, aby uruchomić test w debuggerze:

$ ./waf --run test-runner --command-template="gdb %s --args --suite=mytest --verbose"

3.6.3 Katalog roboczy

Waf powinien być uruchamiany z jego lokalizacji na górze drzewa ns-3. Ten folder staje się katalogiem roboczym, do którego będą zapisywane pliki wyjściowe. Ale co zrobić, jeśli chcesz zapisać te pliki poza drzewem źródłowym ns-3? Użyj argumentu - -cwd:

$ ./waf --cwd=...

Może będzie wygodniej uzyskiwać pliki wyjściowe w twoim katalogu roboczym. W takim przypadku może pomóc takie pośrednie działanie:

$ function waff {
CWD="$PWD" 
cd $NS3DIR >/dev/null 
./waf --cwd="$CWD" $*
cd - >/dev/null 
}

Tego typu dekoracja poprzedniej wersji komendy zachowuje bieżący katalog roboczy, przechodzi do katalogu Waf, a następnie instruuje Waf do zmiany katalogu roboczego z powrotem na zapisany przed uruchomieniem programu bieżący katalog roboczy. Wspominamy o poleceniu - -cwd dla pełności przedstawienia, większość użytkowników po prostu uruchamia Waf z katalogu głównego i tam generuje pliki wyjściowe.

Ciąg dalszy: rozdział 4

Źródło: habr.com