The quickest and most robust way to solve a problem is often to incorporate an existing solution. In project terms - why implement a new feature if we can find an implementation and just integrate it into ours? The answer, usually, is that there's no reason - integrating externally-available functionality is at the heart of much of what we've done in sipXecs, but there are some rules and some processes to be followed to keep it from being disruptive to others and/or harmful to the project.

...

The

...

The following outlines the steps you should take when incorporating an external dependency to ensure that you don't disrupt the work of other developers or the construction of release builds and ISO images.

Component Organization

The top level directory when you check out sipXecs has directories for components, along with a few files that control how those components relate to each other. Mostly, when adding a dependency, you're going to be either adding something to be used by some component or adding an entire standalone component.

Autoconf test for dependency

...

...

The traditional instructions for how to build and open source project from source are to

1. download the source tarball
2. unpack it
3. cd into the directory it creates
4. run configure
5. run make all install

We'd like those instructions to work for sipXecs (a goal we have not really achieved, since to begin with we don't create a single source tarball for everything). We would also would like it to be true that it's easy to get started one step earlier by checking out from the source control system. In order to achieve this, we need to automate as much as possible of the checking for dependencies. We use the GNU build system (see box at right) as our top level build framework, so if you add a dependency, you must add checks to the the files that control the build.

...

Info
This wiki page is not going to attempt to do a full tutorial on autoconf or the other tools we use - for more complete documentation, see the GNU Build System.

configure.ac and the config directory

...

If there is no pre-packaged test for your dependency, you need to write one. You can either should create it in a file config/component.m4, or just edit it into config/general.m4 (for external components) or config/sipXecs.m4 (for other sipXecs components). then include that file in your configure.ac.

Here is a simple test:

# ================ NET SNMP ================
AC_DEFUN([CHECK_FOO],
[
    AC_MSG_CHECKING([for foo includes ])
    include_path="$includedir $prefix/include /usr/include /usr/local/include"
    include_check="foo/foo.h"

    foundpath=""
    for dir in $include_path ; do
        if test -f "$dir/$include_check";
        then
            foundpath=$dir;
            break;
        fi;
    done
    if test x_$foundpath = x_; then
       AC_MSG_ERROR('$include_check' not found)
    else
       AC_MSG_RESULT($foundpath/$include_check)
    fi
])

...

Update ISO package definitions

At present, our ISO image build system does not automatically compute the dependencies needed in the image - the lists for each distribution must be updated manually. Contact whoever has the Release Engineering hat to find out the specifics of what is needed.

Update the Express Development Environment (EDE)

See Express Development Environment Setup for information on the EDE. Making sure that it is updated will keep many of the sipXecs developers from bugging you when you break their builds.