Building, Packaging, and Contributing to adcli
Compiling adcli from Source This describes how to compiling the adcli package from source code. This is normally only necessary for those wishing to contribute to the project or package adcli. You can download tarballs of the releases of adcli or check out the source code from git. This documentation will not go into all the details of how to get your development environment set up and instead focus on the what's unique to compiling adcli.
Dependencies Besides the default autotools, binutils and GCC, adcli requires the following development dependencies to build: OpenLDAP client libraries MIT Kerberos libraries On Debian or Ubuntu you can use the following command to install the dependencies: $ sudo apt-get install build-essential autoconf automake xmlto xsltproc \ libkrb5-dev libldap2-dev libsasl2-dev On Fedora you can use the following command to install the dependencies: $ sudo yum groupinstall "Development Tools" $ sudo yum install automake autoconf xmlto xsltproc krb5-devel openldap-devel \ cyrus-sasl-devel
Building on UNIX adcli uses the standard GNU build system, using autoconf for package configuration and resolving portability issues, automake for building makefiles that comply with the GNU Coding Standards, and libtool for building shared libraries on multiple platforms. The normal sequence for compiling and installing adcli is thus: $ ./configure --prefix=/usr --sysconfdir=/etc... $ make $ make install If you've checked out the source code from git, then the configure script does not yet exist. So use the following instead: $ ./autogen.sh --prefix=/usr --sysconfdir=/etc ... $ make $ make install The standard options provided by GNU autoconf may be passed to the configure script. Please see the autoconf documentation or run ./configure --help for information about the standard options. In particular you probably want to adjust the --prefix=/xxx argument depending on your system and development environment. Make sure that the --sysconfdir=/etc matches the directory where the the MIT Kerberos library stores its krb5.conf. This is usually /etc
Extra Configuration Options In addition to the normal options, the configure script in the adcli supports these additional arguments: , By default adcli is built with debug symbols assertions and and precondition checks. Enabling the debug option configures even more detailed debug build, including disabling optimization. Disabling the debug option is not recommended, as it disables all assertions, preconditions and internal consistency checks, although it may result it a slightly faster library. Disables building of the documentation and command line manual. The documentation is built in the doc/html/ directory of the build. Enables strict checks during building of adcli. All compiler warnings become errors.
Coding Style We use a code style similar to the linux kernel. Use tabs to indent and spaces to align/wrap beyond the indentation level. We don't try to guarantee completely robust and problem free behavior in cases where the caller or system isn't behaving. We consider these to be outside of our control: Broken input from callers. We use preconditions to check input and immediately return. We don't try to provide error codes for all the various ways callers can screw around. Out of memory. It is pretty much impossible to handle out of memory errors correctly. Handling them alongside other errors is naive and broken. We don't try to guarantee library state (such as locks or memory leaks) when memory allocation fails. We do check the results from all memory allocations, but treat them as unexpected conditions. As a nod to the behavior of callers of this library, we don't abort on memory allocation failures. We use preconditions with somewhat sane results. Exception: when reading files or allocating potentially unbounded amounts of memory, we should respond robustly to memory allocation failures. These unexpected conditions indicate a bug either in adcli or in the system. All bets are off once this occurs. Use the return_val_xxx() precondition macros to check for unexpected conditions.
Testing and Code Coverage Low level input parsers and such code should have unit tests exercising it. Use the make check command to run all the tests. If you run it from a subdirectory only the tests in that directory will be run. To check for memory errors or memory leaks, run make memcheck or make leakcheck respectively. This requires valgrind be installed. Build adcli with the configure option to build code coverage support. Once you've done that you can either use make coverage to build code coverage information. Alternatively (and this is usually easier) you can use git coverage to easily check whether you've tested the lines changed by a patch.
Debugging Tips Unexpected conditions will produce critical warnings by adcli. These are often failed internal preconditions, and usually indicate a bug either in adcli or the software calling it. You can use the environment variable ADCLI_STRICT=yes to make adcli do an abort() (and core dump depending on your configuration) when a critical warning occurs.