Developer FAQ

Main Page - Roadmap - Summer Projects - Project Ideas - Developer FAQ - Tools - Related Projects

HOWTOs - Installation - Troubleshooting - User FAQ - Samples - Models - Education - Contributed Code - Papers

Mercurial repository layout for developers

1. In your home dir on code.nsnam.org, you will find a new directory named "repositories/username". e.g.: /home/tomh/repositories/tomh. If you create a repository in this directory, it will appear automatically on http://code.nsnam.org
   • Note: To enable this for new users, edit /var/www/cgi-hg/hgweb.config
2. You can obviously ssh to your personal account and manage these repositories
3. You can push to these repositories with the command: hg push ssh://tomh@code.nsnam.org/repositories/tomh/ns-3-com
4. You can pull with the usual commands: hg clone http://code.nsnam.org/tomh/ns-3-com
5. If you want to allow another user to push into your repository, all you have to do is change the unix permissions of your repository to allow this user write permissions. This means that if you want to give everyone write permissions, you can "chmod -R g +rw /home/tomh/repositories/tomh/ns-3-com/". If you want to allow only a smaller subset of users to push, we will need to create unix group which matches this subset
6. The push command for the main tree is still: hg push ssh://code@code.nsnam.org/repos/ns-3-dev
7. Note: When creating a new repository, avoid cloning it into your directory (which will generate a big ns-commits mail message); instead, just copy or rsync it to the new location.

Mercurial tips

1. How to undo a commit: Let's suppose you are working on a private repository and you check something in, but some other files were inadvertently checked in, and you want to revert and start over. There are two ways to do this:
   1. hg revert: This can be used to revert the repository to a previous revision number. For example, to revert to changeset number #1000, type hg revert -r 1000 --all. This does not remove your checkin from the repository history. For example, if your mistaken checkin was number 1001, and you revert back to 1000 and then commit, you will be at changeset number 1002 now even though the code matches what was in there at changeset 1000.
   2. hg rollback: This can be used to completely wipe clean the last transaction only (commit, import, push, pull). Use with care-- cannot be undone.
2. How to rename a file: hg rename old-file-name new-file-name This is preferable to adding the new file name and removing the old file name, because it preserves revision history. Don't forget to commit once you are done.
3. How to merge a branch: If you have forked a branch repository, have worked on it, and are ready to merge it back to ns-3-dev, here are the steps to take (Also, read this chapter to better understand how the mercurial source tree is structured when merging is occurring):
   1. cd into your branch
   2. hg pull http://code.nsnam.org/ns-3-dev
   3. hg merge
   4. resolve all of the merge issues, if any, and confirm that it builds and validates
   5. hg ci -m"merge your-branch-name with tip"
   6. hg push ssh://code@code.nsnam.org//home/code/repos/ns-3-dev
4. How to create patches for circulation: hg export tip Suppose you don't have write access to the main repositories, but have some patches you'd like to circulate. This command outputs out all the diffs for the latest changeset you committed into your local repository. Simply redirect this output to a file, and you can circulate your patch for consideration. This is for when you have committed changesets. If you would like to export uncommitted changes as a patch, use: hg diff This gets the diffs of all the uncommitted changes versus what is checked into the repository. Redirect to a file for circulation among developers, or for inclusion with a bug report, etc.

The WAF build system

See also the Waf User FAQ.

Obtaining WAF

A snapshot of WAF is distributed with ns-3 releases and mercurial branches. This snapshopt has been tested to work correctly with ns-3, although the trunk version from the main WAF repository usually works equally well.

Documentation resources

There is some incomplete documentation near the bottom of the WAF home page. Some useful tips can be found in the WAF Wiki. Finally, there is a plethora of examples distributed in WAF itself, in the 'demos' directory.

How to add new ns-3 modules

Ns-3 is organized as a set of modules. Each module is built as a separate shared library, has a name, may depend on other modules, and installs a specific set of public header files.

To add a new ns-3 module to the WAF build system, begin by creating a directory under the src/ subtree, with the source files inside. We will use p2p module as example here. Each module needs to define a wscript file. For instance let us see what src/devices/point-to-point/wscript contains:

## -*- Mode: python; py-indent-offset: 4; indent-tabs-mode: nil; coding: utf-8; -*-

def build(bld):
    module = bld.create_ns3_module('point-to-point', ['node'])
    module.source = [
        'point-to-point-net-device.cc',
        'point-to-point-channel.cc',
        'point-to-point-topology.cc',
        ]
    headers = bld.create_obj('ns3header')
    headers.source = [
        'point-to-point-net-device.h',
        'point-to-point-channel.h',
        'point-to-point-topology.h',
        ]

A wscript file is basically a special python module. The main entry point to this module is the build(bld) python function.

In the code above, the module variable represents a ns-3 module; internally it is a WAF 'objects' build object that will be linked to be come part of the ns3 library. It is created by calling a special method bld.create_ns3_module, whose first parameter is the name of the module, and the second parameter is a list of other modules that this module depends on. Additionally, module.sources has to be set to the list of source files (excluding header files) that constitute the module. Warning: beware that the name of the module must match the name of the directory where it is built. In this case, the module is in 'src/devices/point-to-point', so the module name must be 'point-to-point'.

There is usually also a headers object. It is used to declare public header files. These files are copied to the build directory, and can be included from any module with #include "ns3/header-name.h".

A final step, after the wscript file is created, is to register it. Open the file src/wscript and add the new module to the all_modules list variable:

all_modules = (
    'core',
    'common',
    'simulator',
    'node',
    'internet-node',
    'devices/point-to-point', # <---- example here
    'applications',
    )

Adding programs

Use the special method bld.create_ns3_program(name, [...dependencies...]). Example:

    obj = bld.create_ns3_program('main-simple',
                                 ['node', 'internet-node', 'applications'])
    obj.source = 'main-simple.cc'

Submitting patches for consideration

When you send a tree without a detailed summary of your changes, it would help if you could send a list of the changesets you want to merge. To generate it, first merge with ns-3-dev and then, from your modified directory, run "hg outgoing -p http://code.nsnam.org/ns-3-dev"

Also, avoid spurious coding style and whitespace changes when preparing such a patch, as it distracts from the readability of your proposed technical changes.

Checking in code

just before you do a checkin you should run the regression tests. Change into the regression directory and type

 python regression.py

If you do this now, you will see a bunch of passing tests and then,

 ----------
 Traces differ in test: test-tcp-large-transfer
 Reference traces in directory: ns-3-dev-ref-traces/tcp-large-transfer.ref
 Traces in directory: traces
 Rerun regression test as: "python regression.py test-tcp-large-transfer"
 Then do "diff -u traces ns-3-dev-ref-traces/tcp-large-transfer.ref" for details
 ----------
 FAIL test-tcp-large-transfer

Now, this "failure" is most likely due to someone checking in a change this afternoon that added TCP delayed acks.

If you make a change like this, you'll need to update the reference traces for the new behavior. All you have to do is to change into the regression directory and run the test in question (here test-tcp-large-transfer) with the -g (generate) option, as in

 python regression.py -g test-tcp-large-transfer

This will write new reference traces into the proper place in the "ns-3-dev-ref-traces" directory. In this case, look in the directory,

 ns-3-dev-ref-traces/tcp-large-transfer.ref/

You need to that the new traces are what you expect to see given your change. If you don't expect to see any changes, you may have a real regression and you'll need to debug it.

Assuming that the new traces represent new expected behavior, you just need to push the new bits into the ns-3-dev-ref-traces repository.

 cd ns-3-dev-ref-traces
 hg push ssh://code@code.nsnam.org//home/code/repos/ns-3-dev-ref-traces