BakeIntegration

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

HOWTOs - Installation - Troubleshooting - User FAQ - 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.

Assume that a third party developer releases and maintains a module of ns-3 (e.g. ns3-bgp). This module may be maintained as a distribution package, source tarball, or source code repository (git, hg, cvs) somewhere on the public internet. Third party developer (or ns-3 maintenance team) adds items to the bakeconf.xml file to allow future users to perform an operation such as:

 bake.py configure -e ns3-bgp
 bake.py download  # will download any dependencies also part of the bake universe
 bake.py build     # will build according to dependencies
 bake.py install   # will install headers and libraries to a well-known place where ns-3 ./waf knows to search

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. bake.py provides existing download.py and build.py with no change of functionality

 hg clone http://code.nsnam.org/ns-3-allinone
 cd ns-3-allinone
 ./bake.py download
 ./bake.py build

or for a release tarball

 tar xjf ns-allinone-3.16.tar.bz2
 cd ns-allinone-3.16
 ./bake.py build

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

 ./bake.py list
 
 click-1.8.0
 openflow-ns3
 ns-3-dce  (disabled)
 gccxml-ns3 (disabled) 
 pygccxml (disabled) : gccxml-ns3
 pybindgen
 nsc
 ns-3-dev
 netanim

In the example above, the gccxml-ns3 dependency is shown for pygccxml. It is out of scope for bake.py 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 "bake.py build" reports this to a user in a nice way so the user can try to find/install the missing package.

 ./bake.py configure -d netanim

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

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

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

3. bake.py 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:

 ./bake.py configure -e ns-3-bgp
 ./bake.py download
 ./bake.py build       # builds ns-3, then builds ns-3-bgp
 ./bake.py 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 explicitly specifying the path to ns-3-bgp; i.e. waf may need to become smarter to find these headers and libraries.

4. bake.py 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.