BakeIntegration

From Nsnam
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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.