App Store Technical Requirements
Devise a new source code organization, build system, and package management (metadata and scripts) system that provides the following.
The top level goals are as follows:
- Modular build, with capability to enable/disable models from the build
- Package management system, to allow users to manage model packages that are provided by ns-3 as well as those that may be provided by third parties
- Uniform way to handle and manage (non-system) external libraries used with ns-3
Beyond modularity, there is a need to distinguish the maintenance status of models:
- ns-3-dev continues to contain the core models, test suites, and documentation that are actively maintained by the project and built by all users
- ns-3-models contains additional models that can be added to the build with user-friendly build instructions. There will be two classifications:
- maintained: These contain models that are actively maintained by the project. All models in this directory are checked for each release, and bugs in tracker are responded to
- unmaintained: These contain models that conform to the package metadata system, but the project does not do any testing or maintenance of them. They may fall out of date over time. They may be revived in the future and added to the maintained status.
- models can also be stored at external web sites; such models will typically have "unmaintained" status. Note that "unmaintained" means unmaintained by the project; someone may be actively maintaining them behind the scenes.
The basic idea of the ns-3 app store would be to store on a server a set of user-submitted metadata which describes various source code packages. Typical metadata would include:
- unique name
- version number
- last known good ns-3 version (tested against)
- download url
- untar/unzip command
- configure command
- build command
- system prerequisites (if user needs to apt-get install other libraries)
- list of ns-3 package dependencies (other ns-3 packages which this package depends upon)
There are a few metadata systems to be considered, such as Debian spec files and jhbuild.
API and work flow
There are separate tasks that people will want to do on a per-module basis, and perhaps on a top-level repository with specific components enabled/disabled:
- download code
- update code
- configure; enable/disable them from the build
- enable optimized/debug
- build, compile, and link model code
- install: copy exported .so binaries, .h to an "install" location (maybe specified during configure)
- build examples: compile and link examples
- build tests: compile and link etsts
- run tests
- generate documentation
One idea is to have a workflow like this:
hg clone http://code.nsnam.org/build cd build ./build.py module-list.xml download ./build.py module-list.xml configure ./build.py module-list.xml build ./build.py module-list.xml install
module-list.xml would describe the list of modules to build, for each module the list of commands for each task.
It probably makes sense to first consider how to factor out an existing model into a new library, and how we want the build system to handle that case (such as what we used to do a long time ago with separate simulator, core, common, etc. libraries). Then, we could talk about how to maintain such separate model libraries as packages.