Bake: Main Page View

What is Bake?

Bake is an integration tool which, when ready, is intended to be used by software developers to automate the reproducible build of a number of interdependent projects. These projects, even though dependent on each other, may be developed and hosted, by unrelated parties. It is developed to be the automatic building tool for the ns-3 project. However, the tool itself intends to be generic and susceptible of being used in other contexts, i.e. by other projects with needs similar to the ns-3 one.

Bake is primarily intended for people who want to work within the source code of the simulator/modules, and have to manage lots of different modules.

What bake is not!

- Bake is not a waf, make, autoconf or automake, .rpm, .deb replacement.

Compared to JHBuild

- JHBuild is a tool or automatically download and compile "modules" (i.e. source code packages). It handles variety of sources (CVS, Subversion, Git, Bazaar,...) and handle automatically dependencies. JHBuild was originally written for building GNOME, but has been extended to many other projects.

- The biggest problem with JHBuild is its lack of support for packages that are not natively autotools-fluent. In fact, the hardest problem in bake is how we can deal with projects that have wildly different build systems.

- Bake was built to be more flexible and configurable than JHBuild. Bake is made for people who need to build various different modules, within a specific configuration. It does not try to target people who just want versioned pre-built libraries.

How it works?

From the point of view of Bake users, there are two steps to fulfill for using the tool. First, it is necessary to access to a server, in order to download a customized configuration file, with specifies all the modules the user is interested in. The client side will be responsible for downloading the required modules and dependencies, and building the module, and dependencies, in the right order.

We have two target users for Bake:

- Developers: Who will contribute with modules descriptions to the server side
- Simulator users: Who are interested on use the simulator and some specific modules

Intended flow:

1. Developers: add the meta data describing their modules, e.g. who developed, what it does, where to find it, which tool to use to make the build...
2. Simulator Users: select the modules they have interest into
3. Simulator Users: download the description file into their own machines
4. Simulator Users: use the client bake to download the selected modules, and its dependencies, directly to their machines
5. Simulator Users: use the client bake to make a consistent, adapted to their architecture and reproducible build of ns-3 and the selected modules

Already installed ns-3 versions:

When the user is installing a new module Bake will search for already installed versions of ns-3 on the user's path and on the default installation directory (for .rmp and .deb installations). If Bake finds any already installed version, it verifies two things, first the present installation is compatible with the requirements of the target module. Second, if the user has the right to install modules within that specific repository. If the versions are compatible, and the user has the rights, Bake will install the new module on the found repository. If not, there is no pre-installed version or the user has no writing permissions, Bake downloads all the dependencies and builds them on the specified build directory. Of course the users can choose to ignore any installed version and make a new clean installation every time.

This part of Bake is not implemented yet and in fact it is still quite open. We would REALLY welcome inputs from the community about how it would be the best way to handle pre-existent installations.

To use Bake

Prerequisites:
- Python 2.7, or higher - The target tools for each specific repository/build tool you will try to use * It is important to notice that you only NEED to have installed the tools you will use. For example, If you will try to build packages that uses mercurial as repository you need to have mercurial installed, if you will download a zip, all in one kind of file, you need to have zip installed. The same for the build tools, if you will build a module that relies, for example, on Cmake, you need to have Cmake installed. If you will not use the tool, you don' t need to have it installed on your machine.
Download:
The most recent version of the client bake can be found at: http://code.nsnam.org/daniel/bake/ - hg clone http://code.nsnam.org/daniel/bake
Full description file:
For now, just use the bakeconf.xml file that came with the client bake, so that you have a taste of what the client can do. * This file will work, some how, as the server for you. It has a description of a series of modules that can be already build with the bake client. When the real server will be ready, one will be able to download the customized file, the one just after the configuration.

Some small examples

Here we will present some simple bake used cases. For now, bake is only linux compatible, the $ means the prompt into a linux machine, and what cames next is the comand that should be executed.
To install:
$ hg clone http://code.nsnam.org/daniel/bake $ cd bake
Options :
$ python bake.py --help Usage: bake.py [options] command [command options] Where command is one of: install : Downloads the configured modules AND makes the build in one step configure : Setup the build configuration (source, build, install directory, and per-module build options) from the module descriptions reconfigure : Update the build configuration from a newer module description download : Download all modules enabled during configure update : Update the source tree of all modules enabled during configure build : Build all modules enabled during configure clean : Cleanup the source tree of all modules built previously shell : Start a shell and setup relevant environment variables uninstall : Remove all files that were installed during build show : Report on build configuration show-builtin : Report on builtin source and build commands To get more help about each command, try: bake.py command --help Options: -h, --help show this help message and exit -f CONFIG_FILE, --file=CONFIG_FILE The Bake file to use. Default: bakefile.xml. --debug Should we enable extra Bake debugging output ?
Simple install with the file from the bake server
> Thanks to Gustavo Carneiro for the suggestion. python bake.py [-f <configuration file>] install - Downloads and makes the build Examples: $ python bake.py -f bakeServerConfigFile.xml install
To install one module:
python bake.py [-f <configuration file>] configure -c bakeconf.xml [-e <name of the target module>] - Creates a configuration file, by default called bakefile.xml, that has all the required information to download and build the target module python bake.py [-f <configuration file>] download - Downloads the module, and its dependencies, to a directory called source python bake.py [-f <configuration file>] build - Builds the modules into a directory called build Examples: - To install, for example, open flow $ python bake.py configure -c bakeconf.xml -e openflow-ns3 $ python bake.py download $ python bake.py build - To install, ns-3 dev $ python bake.py -f nsfile.xml configure -c bakeconf.xml -e ns-3-dev $ python bake.py -f nsfile.xml download $ python bake.py -f nsfile.xml build
To install ALL modules:
Warning!!!! This will take some time :) python bake.py [-f <configuration file>] configure -c bakeconf.xml -a - Creates a configuration file, by default called bakefile.xml, that has all the required information to download and build ALL the available modules python bake.py [-f <configuration file>] download - Downloads the modules, and its dependencies, to a directory called source python bake.py [-f <configuration file>] build - Builds the modules into a directory called build Example: - To install, all the modules available on the bakeconf.xml file $ python bake.py configure -c bakeconf.xml -a $ python bake.py download $ python bake.py build