From Nsnam
Revision as of 15:38, 18 October 2012 by Danielcamara (Talk | contribs) (ns-3.16 goals)

Jump to: navigation, search

Main Page - Current Development - Developer FAQ - Tools - Related Projects - Project Ideas - Summer Projects

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

This page is for describing functional requirements of the bake tool for ns-3.16 and for future releases.

Broad functional goals

1. Enable a more distributed package environment for ns-3 third-party developers.

1.1 Split out some of existing ns-3-dev into a smaller "core" and additional "extensions". This should reduce build time for users.

1.2 Provide straightforward way for a third-party developer to maintain their own ns-3 extension and make it available to ns-3 users.

2. Provide a tool for developers to manage multiple builds.

3. Start to provide access to INRIA's Direct Code Execution (DCE) environment

ns-3.16 goals

Below are proposed goals for ns-3.16.

1. provides existing and with no change of functionality

 hg clone
 cd ns-3-allinone
 ./ configure -e ns-3-dev
 ./ install

or for a release tarball

 tar xjf ns-allinone-3.16.tar.bz2
 cd ns-allinone-3.16
 ./ install

1.1 different levels of verbosity show different amount of build information

 ./ install 

yields something sparse, such as

 >> Downloading ns-3-dev
 >> Download ns-3-dev - OK 
 >> Building ns-3-dev
 >> Built ns-3-dev - OK

while this:

 ./ install -vv

might yield the full build output (full waf configure and build information). (this appears to be already supported)

1.2 How to specify ns-3 configure options to bake? e.g. one can pass options such as "--disable-python" to

1.3 How to manage debug, optimized, and static builds?

1.4 Control-C signal handling (only a single Control-C should stop all builds)

1.5 does not rebuild things unnecessarily.

2. shows available packages, whether they are enabled, and their dependencies; e.g.:

./ show --enabled
 module: click (enabled)
   No dependencies!
 module: openflow-ns3 (enabled)
   No dependencies!
 module: gccxml-ns3 (enabled)
   No dependencies!
 module: nsc (enabled)
   No dependencies!
 module: qt4 (enabled)
   No dependencies!
 module: pygccxml (enabled)
   depends on:
      gccxml-ns3 (optional:True)
 module: net_anim (enabled)
   depends on:
      qt4 (optional:True)
 module: pybindgen (enabled)
   depends on:
      pygccxml (optional:True)
 module: ns-3-dev (enabled)
   depends on:
      net_anim (optional:True)
      nsc (optional:True)
      pybindgen (optional:True)
      click (optional:True)
      openflow-ns3 (optional:True)

In the example above, the gccxml-ns3 dependency is shown for pygccxml. It is out of scope for to manage package dependencies for some of these (e.g. showing "scons" as a dependency for nsc). However, it would be nice if, during the course of the build, if a package configure bails out, that " build" reports this to a user in a nice way so the user can try to find/install the missing package.

The user can check the missing dependencies by calling:

./ check
 > Python - Ok
 > Mercurial - Ok
 > CVS - Ok
 > Bazaar - Ok
 > Tar tool - Ok
 > Unzip tool - Ok
 > Unrar tool - Ok
 > GIT - is missing
 > Make - Ok
 > cMake - Ok
 > path tool - Ok
 > Autotools - Ok

Perhaps an enhancement to the above would be to show the "build" and "install" status of each.

Users should be able to disable (in a sticky way) a package they are not interested in; e.g.:

 ./ configure -d netanim

would result in netanim being "(disabled)". Either of the following would restore netanim:

 ./ reconfigure  (or some other way to get back to defaults)
 ./ configure -e netanim

3. allows at least one "external" ns-3-based module to be downloaded and built with ns-3. For example, assume there is an external routing protocol module (ns-3-bgp); we may need to make one of these up for the sake of providing an example.

For ns-3-bgp to build, it needs to link to ns-3 libraries. So, there needs to be some install step in bake to install to a well-known place in the allinone directory, or in the system.

For a user program in ns-3.16/scratch to use ns-3-bgp, it needs to be able to find the library and headers. So, the install step on ns-3-bgp should leave the installation in a well-known place by ns-3's waf.

So, the goal here would be:

 ./ configure -e ns-3-bgp
 ./ download
 ./ build       # builds ns-3, then builds ns-3-bgp
 ./ install     # installs both (does install have to happen before ns-3-bgp build?)

Then, user program in ns-3.16/scratch/ can include the module without specifying the full path to ns-3-bgp; i.e., waf may need to become smarter to find these headers and libraries.

4. provides access to ns-3 DCE with at least one well-documented example (iperf? quagga?) of how to use real application code within an ns-3 program. Perhaps we focus on user-mode applications for ns-3.16 and kernel-mode for the next release.

5. debug, optimized, and static builds are managed coherently. (Suggestions on this point would be welcome)

Beyond ns-3.16

To be determined.