|
Index |
|||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| - How it
works? - How to use Bake - Some small examples - Modules description |
|||||||||||
| How it works? | < top > | ||||||||||
| |
|||||||||||
|
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. |
|||||||||||
 |
|
||||||||||
| 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. |
|||||||||||
|
How to use Bake |
< top > | ||
|---|---|---|---|
| |
|||
| 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 |
< top > | ||
|---|---|---|---|
| |
|||
| 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 comes next is the command 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 |
|||
|
Modules description |
< top > | ||
|---|---|---|---|
| |
|||
| Bake is
prepared to handle the most popular building and version
control tools. However, to enable bake to automatically
build the modules one needs to provide a description of
the target module in a format bake can handle. This
description should precisely describe the tools used in
the module development, its dependencies and where bake
can find a copy of the code. When using the server side,
the module store, this file will be provided
automatically. However, if one want to add an entry to the
server, or want to create a module description to personal
use, it is important to know how the module description is
made. Here we will present the format of the description file and all the available options to configure the module build process. |
|||
| Configuration
file format: |
|||
<configuration> <modules>
<module name="NameOfTheModuleToBuild">
<source type="SourceRepositoryType">
<depends_on
name="ModuleNameThatThisModuleDeppendsOn"
optional="False"/>
<build
type="BuildToolType" objdir="build">
</module>
<module name="ModuleNameThatThisModuleDeppendsOn">.....
</module>
<module name="AnotherModuleThisModuleDeppendsOn">.....
</module>
</modules></configuration> |
|||
| Module
tag: |
|||
The
module tag describes the module name, this name is used to
identify the module. The module tag may contain the
following sub tags:
|
|||
| Source
sub-tag: |
|||
| The
source stores the information related to where to find the
source code for the target module. The available source tag options are:
* $SRCDIR, $OBJDIR, $INSTALLDIR tags may be used by the developer to reference local directories, on the user's machine, that will store, respectively, the source code, the object code and where the build code should be installed. |
|||
| Build
sub-tag: |
|||
| The
build sub-tag stores the information related to the tools
used to build the source code and about the module
installation process . The available build tag options are: Options valid for all available building methods Available building methods: autotools, cmake, inline, make, python, waf
* $SRCDIR, $OBJDIR,
$INSTALLDIR tags may be used by the developer to
reference local directories, on the user's machine, that
will store, respectively, the source code, the object
code and where the build code should be installed.
|
|||
| depends_on
sub-tag: |
|||
| The
depends_on sub-tag makes it explicit the dependencies of
the target module over other defined modules, these other
modules should also be defined in the description
file. The dependency may be optional or not. Optional dependencies means that the module "softly" depends on the other module, i.e. It would be good to have, but if something happens the module will work without the dependency. For example, ns-3 has optional dependencies on many modules, e.g. openflow, however, if the user does not use openflow, there is no need to install it. Thus, if something happens during the building process of these optional dependencies the whole building process does not stop. On the other hand, if there is a problem during the compilation of a non optional dependency, that means the module, that is really needed, will not be ready to be used by the module. In this case, if the dependency is not met, the building process is aborted.
|
|||
