Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin
Wiki Markup


h1. Build Architecture

The asterisk build architecture relies on autoconf to detect the system configuration, and on a locally developed tool (menuselect) to select build options and modules list, and on gmake to do the build.

The first step, usually to be done soon after a checkout, is running "./configure", which will store its findings in two files:

* include/asterisk/autoconfig.h
** contains C macros, normally #define HAVE_FOO or HAVE_FOO_H , for all functions and headers that have been detected at build time.  These are meant to be used by C or C++ source files.

* makeopts
** contains variables that can be used by Makefiles.  In addition to the usual CC, LD, ... variables pointing to the various build tools, and prefix, includedir ... which are useful for generic compiler flags, there are variables for each package detected.  These are normally of the form FOO_INCLUDE=... FOO_LIB=... FOO_DIR=... indicating, for each package, the useful libraries and header files.

The next step is to run "make menuselect", to extract the dependencies existing between files and modules, and to store build options.
menuselect produces two files, both to be read by the Makefile:

* menuselect.makeopts
** Contains for each subdirectory a list of modules that must be excluded from the build, plus some additional informatiom.

* menuselect.makedeps
** Contains, for each module, a list of packages it depends on.  For each of these packages, we can collect the relevant INCLUDE and LIB files from makeopts. This file is based on information in the .c source code files for each module.

The top level Makefile is in charge of setting up the build environment, creating header files with build options, and recursively invoking the
subdir Makefiles to produce modules and the main executable.

The sources are split in multiple directories, more or less divided by module type (apps/ channels/ funcs/ res/ ...) or by function, for the main binary (main/ pbx/).

This section is not complete...

h1. Adding new modules

If your module is going in the {{addons/}} directory, you must edit {{addons/Makefile}} and add it to the list of modules assigned to the {{ALL_C_MODS}} variable.  Once that is done, continue to the next steps.  For any other directory, just continue.

h2. Modules with no dependencies

If your module has no dependencies on external libraries, it can be dropped into the appropriate directory and the build system will automatically detect it and build it for you.  For example, if you write {{app_custom.c}}, drop it in the {{apps/}} directory.

h2. Modules with dependencies

If your module has an external dependency, you have a bit more work to do to integrate it into the build system.  First, you must determine whether the library you are using is used by any other Asterisk module.  If not, you must add the library to the following files.

h3. {{}}

This is the source of the configure script.  There are _many_ examples to draw from in this file.  Search for the two instances of {{ALSA}} in this file to find one of the simpler examples of checking for a library.

h3. {{build_tools/}}

Add a line in this file for your new library.  The configure script uses this file as input and outputs build_tools/menuselect-deps.  The {{menuselect}} utility reads in this file to know which libraries have been found on the system.

h3. {{}}

Add {{LIBNAME_LIB}} and {{LIBNAME_INCLUDE}} lines into this file.  The configure script will use this file as input and output the {{makeopts}} file.  When this library is found, these lines will have the appropriate {{CFLAGS}} and {{LDFLAGS}} needed to build and link a module with the library.  Follow the other examples that are already in this file for formatting.

h3. Update your module

Modules that have a dependency must have a special comment block in them that is used by the build system.