BakeIntegration

From Nsnam
Revision as of 15:35, 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. 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 configure -e ns-3-dev
 ./bake.py install

or for a release tarball

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

1.1 different levels of verbosity show different amount of build information

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

 ./bake.py 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 build.py.

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 bake.py does not rebuild things unnecessarily.

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

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

The user can check the missing dependencies by calling:

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

 ./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

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 specifying the full 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.