Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

./configure options of note

These are options passed to the

./configure

command after calling

autoreconf

but before calling

make build
  • Sending build output to a different directory. This is handy when you want to mass delete all build output when you want to start over. Its also handy for creating multiple build with differnent configuration

    mkdir my-build-output
    cd my-build-output
    ../configure

  • To see all configuration options, run the following command, it can be quite overwhelming! and unfort. quite redundant

    --help=recursive

  • If you're not going to read the C++ documentation, this will speed things up

    --disable-doxygen

  • If you are not interested in openfire support

    --disable-openfire

  • If you have installed the openfire RPM in a non standard location (i.e. other than /opt/openfire) :

    OPENFIRE_HOME=path-to-openfire

  • Handy when you want server to run as the user building the source so you can debug easier and gdb/ddd will find source automatically

    SIPXPBXUSER=`whoami`

  • If you plan to install multiple builds, you can direct the installation to a directory other than
    /usr/local/sipx
    by adding this switch. You can use any directory name

    --prefix=/opt/sipx

  • If you want CDR support, add the following option. (Requires ruby and development tools like gem and rake)

    --enable-cdr

  • To speed up
    configure
    step, this can decrease the time by 40%. You can use any file name

    --cache-file=/tmp/ac-cache-file

  • If you change Makefile.in in the top directory you can just run this command to regenerate Makefile

    --no-recursion

  • What is also good for people doing builds in the same directory often, is to use ccache. For example for centos or redhat you would install the ccache rpm from dag wiers repository at: http://dag.wieers.com/packages/ccache/, on FC try

    sudo yum install ccache

    1. and than add the following settings to your environment:
      export CC="/usr/bin/ccache gcc"
      export CXX="/usr/bin/ccache g++"

autotools tips of note

  • After running
    autoreconf -if
    once, subsequent times you can just run
    autoreconf
    to speed things up a bit

    autoreconf -if

    subsequently if you make a change to any configure.ac or autoconf macro

    autoreconf

  • To re-run a
    configure
    script from the build target directory. (Thanks to Damian K. for finding this one.)

    ./config.status --recheck && ./config.status

make options of note

  • To skip unit tests, only skip them if you know what you are doing

    make recurse TARGETS="all install"

  • To build only the one target and dependencies

    make PROJECTS="sipXregistry sipXvxml"

  • To build only the one target without dependencies

    make PROJECTS_ORDERED="sipXregistry sipXvxml"

  • To supress some (but not nearly all) extraneous output

    make -s

  • To list all the projects in order that they would build

    make list

  • To make rpms. NOTE. This will use sudo to install RPMs as it builds them. This is an unfortunate necessity of how we've decoupled each project

    make rpm

  • If you edit a Makefile.am, you may not have to re-run
    autoreconf
    or
    configure
    . Built into the Makefile is the ability to regenerate itself, simply run your target as you normally would. If you make a change that is of improper syntax, you will have to rerun
    autoreconf
    and
    configure

Troubleshooting

  1. If autoreconf produces error messages containing symbols that contain "CXX", you probably don't have the autoconfigure support for C++ sources installed. This may mean you need to install the C++ support for your distro, or that your installed autoconfigure needs updating.
  2. If your build reports errors on named related tests, you do not have the nameserver running or your nameserver is mis-configured. In this case edit out the offending tests.
  3. If you are running on older harware some of the timer related tests may report errors. Ignore these errors.
  4. Keep your build environment clean. It is best to not have the sipx*devel tools installed on the machine ( or virtual machine file system ) where you want to build your source code. You can pick up stale libraries and includes that can drive you up the wall. If you are building RPMS, note that RPMS are also installed when you build them. You can list all the installed RPMS using rpm -q -all.
  • No labels