Difference between revisions of "BakeIntegration"

From Nsnam
Jump to: navigation, search
(ns-3.16 goals)
(ns-3.16 goals)
Line 60: Line 60:
  
 
   ./bake.py show --enabled
 
   ./bake.py show --enabled
 
+
module: click (enabled)
  click-1.8.0
+
   No dependencies!
   openflow-ns3
+
module: openflow-ns3 (enabled)
  ns-3-dce  (disabled)
+
   No dependencies!
   gccxml-ns3 (disabled)  
+
module: gccxml-ns3 (enabled)
   pygccxml (disabled) : gccxml-ns3
+
   No dependencies!
   pybindgen
+
module: nsc (enabled)
   nsc
+
  No dependencies!
  ns-3-dev
+
module: qt4 (enabled)
   netanim
+
  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.
 
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.
 
Perhaps an enhancement to the above would be to show the "build" and "install" status of each.

Revision as of 15:35, 18 October 2012

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.