Profanity Illustration

User Guide

Manual Building

Contents

Building

Profanity uses the Autotools for it's build system. The Autotools consist of Autoconf and Automake. This page doesn't go in any detail about the Autotools, but describes the commands needed to build Profanity, and brief descriptions of the various stages. You will also need autoconf-archive.

You can either download the archive from the homepage or use git, a version control system, to get the latest code.

If you want to get the latest version from git you'll have to do:

git clone https://github.com/profanity-im/profanity

After obtaining the source code, and extracting it, use the following commands to build and install

./bootstrap.sh
./configure
make
make install

The first step is only needed if you pulled from git

The final step requires root privileges.

Various dependencies are required to install Profanity, the ./configure script will fail if the minimum dependencies cannot be found.

The latest code in master is also kept up to date with development changes to libmesode/libstrophe, so a manual build of this library may also be needed, see the README at libmesode.

Dependencies

The package names below are from Ubuntu and may differ per distribution.

Build dependencies:

automake
autoconf
autoconf-archive
libtool
pkg-config

Required dependencies:

Profanity can be built against either libstrophe, or libmesode. Libmesode has a few extra features around manual TLS certificate verification. Version 0.6.0 (and above) of Profanity requires version 0.9.2 of libstrophe or libmesode.

Profanity also requires:

libncursesw5-dev
libglib2.0-dev
libcurl3-dev
libreadline-dev

Optional dependencies:

libnotify-dev            # Desktop notification support
libxss-dev               # Desktop idle time autoaway support
libotr5-dev              # OTR support
libgpgme11-dev           # PGP support
libsignal-protocol-c-dev # OMEMO support
libgcrypt-dev            # OMEMO support (>= 1.7)
libgtk2.0-dev            # Desktop tray icon support
python-dev               # Python plugin support
libcmocka-dev            # To run tests
shared-mime-info         # Send files with the correct mime type

Distribution details:

To make it easier to install all the required packages in various distributions we collect copy pastes here.

Debian

apt-get install libssl-dev libexpat1-dev libncursesw5-dev libglib2.0-dev libnotify-dev libcurl3-dev libxss-dev libotr5-dev libgpgme11-dev autoconf-archive expect-dev tcl-dev libtool python-dev libgtk2.0-dev automake autoconf libtool pkg-config libsignal-protocol-c-dev libgcrypt-dev libreadline-dev

openSUSE

zypper in gcc automake autoconf libtool glib2-devel gtk2-devel libcurl-devel libexpat-devel libgpgme-devel libmesode-devel libnotify-devel libotr-devel libuuid-devel ncurses-devel python3-devel readline-devel autoconf-archive libsignal-protocol-c-devel libgcrypt-devel

Arch Linux

pacman -S --needed autoconf autoconf-archive automake base-devel check cmake cmocka curl doxygen expat gcc git gpgme gtk2 libgcrypt libnotify libotr libtool libxss make openssl pkg-config python wget

Mac OS

brew install autoconf autoconf-archive automake libtool pkg-config glib gnutls gpgme libotr libstrophe openssl ossp-uuid readline terminal-notifier libsignal-protocol-c

Some required packages are "keg-only", which means they are not symlinked into /usr/local, therefore pkg-config will fail when detecting the libraries and the build will fail. In order to fix this we need to add these packages to the PKG_CONFIG_PATH.


export PKG_CONFIG_PATH="/usr/local/opt/ncurses/lib/pkgconfig:$PKG_CONFIG_PATH"
export PKG_CONFIG_PATH="/usr/local/opt/expat/lib/pkgconfig:$PKG_CONFIG_PATH"
export PKG_CONFIG_PATH="/usr/local/opt/curl/lib/pkgconfig:$PKG_CONFIG_PATH"
export PKG_CONFIG_PATH="/usr/local/opt/openssl/lib/pkgconfig:$PKG_CONFIG_PATH"
export PKG_CONFIG_PATH="/usr/local/opt/libffi/lib/pkgconfig:$PKG_CONFIG_PATH"
            

Helper script

A helper script has been written to install all required and optional dependencies and run the above steps. This script currently supports Ubuntu, Fedora, Centos, openSUSE and Cygwin.

Download the script into the project directory and run it:

wget https://profanity-im.github.io/install-all.sh
chmod u+x install-all.sh
./install-all.sh

The script might not be entirely up to date!

Explanations:

Input files

configure.ac – Macro definitions to configure profanity for the target environment (autoconf)

Makefile.am – Template Makefile (automake)

These files are the inputs to generating the actual configure script and Makefile required to configure and compile Profanity.

Generating a configure script

To generate the configure script:

./bootstrap.sh

This phase only needs to be run when changes have been made to configure.ac, however it does no harm to run it on every build. This phase also generates other files needed to create a config.h header (variables used in the main code), and a Makefile (used for compilation).

Why not just write configure yourself, instead of writing configure.ac and generating one with bootstrap.sh? Take a look at the generated configure script and you'll see why, there's a lot of work involved in writing a configure script.

The bootstrap.sh file is very simple, it just runs autoreconf --install see autoreconf

Configuring

Once the configure script has been generated, run it to configure profanity.

./configure

This will result in the following being generated, along with some other files:

src/config.h
Makefile

Compiling

The following step will then compile Profanity:

make

Once you have run ./bootstrap.sh and ./configure once, if all you are doing is making code changes, then you only need to run make to recompile your changes.

To perform a clean build (i.e. remove all compiled files and recompile)

make clean
make

Tests

All tests (unit and functional) can be run with:

make check

Unit tests alone can be run with:

make check-unit

Install

Once you have compiled profanity with make, the executable will be available in the current directory:

./profanity

To install this version on your system, i.e. to be able to run it from anywhere:

sudo make install

This step is not really necessary when doing development (i.e. you can always run the version just compiled in the project directory), unless you want to have your development version available to any users on your system.