Build system

This was written in 2010. In 2017, the GNU Telephony project primarily uses CMake.


The GNU Telephony project now has a new “make-in-place” build system to build directly from a SVN checkout of our entire build tree. This can now be found on the Sourceforge SVN repository for GNU Telephony (svn co What this allows one to do is configure, build, and run all parts of GNU Telephony without having to do partial make install for dependent libraries or the need to create “fake roots” if one is a guest on a machine without root access.

Make-in-place uses existing pkgconfig, automake, and libtool functionality to achieve this, along with a master top level configure script and Makefile. This makes it very easy to deploy automated compile farms, to generate embedded & cross-compile build profiles, or to develop on hosts where different/conflicting versions of existing packages we offer may already be installed.

A special category of helper scripts are found in the config directory for each package. These .ex files are used to indicate how to translate pkg-config directory references, how to link additional headers, etc.

It is possible to use Eclipse with Make-in-place.

Using Eclipse

There are two ways one can use Eclipse with GNU Telephony.

The first method involves importing each package, perhaps directly from CVS from GNU Telecom Subsystem (GnuComm) on, or using subclipse to import from our Sourceforge SVN repository. This method one can build code either as a local C++ “make” project, or perhaps even as an automake-managed project supported by newer versions of CDT and the automake support plugins.

Using this method, each package is maintained as a standalone entity. This means if dependent libraries are needed, they must be installed first. One might also have to build make install targets to get needed libraries out for other parts of GNU Telephony. There is a second approach possible, however, which can be used in conjunction with our Make-in-place build scripts.

To use Eclipse with Make-in-place builds, you would start with a clean checkout of the entire build tree. You would then do the following steps:

You now have projects filled with local Eclipse-managed copies of the make-in-place build tree. They are configured to use include files from the make-in-place tree, and to link their libraries from there. You can now use Eclipse for all your primary editing and make. You will need to export back to the build tree, and run make there to get dependent libraries to relink with changes (such as ucommon for sipwitch) if they are modified, however.

There is also an Eclipse filesync plugin to automatically export changes back to the original file system/make-in-place directory tree. You can add a make target to run make from there to force the library to rebuild in the make-in-place tree from within Eclipse and automate this part.