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
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
yields something sparse, such as
>> Downloading ns-3-dev >> Download ns-3-dev - OK >> Building ns-3-dev >> Built ns-3-dev - OK
./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 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.
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)
To be determined.