1Doing the build 2=============== 3 4.. _do_build: 5 6Building within a single tree 7----------------------------- 8 9If you only need to build Kerberos for one platform, using a single 10directory tree which contains both the source files and the object 11files is the simplest. However, if you need to maintain Kerberos for 12a large number of platforms, you will probably want to use separate 13build trees for each platform. We recommend that you look at OS 14Incompatibilities, for notes that we have on particular operating 15systems. 16 17If you don't want separate build trees for each architecture, then use 18the following abbreviated procedure:: 19 20 cd /u1/krb5-VERSION/src 21 ./configure 22 make 23 24That's it! 25 26Building with separate build directories 27---------------------------------------- 28 29If you wish to keep separate build directories for each platform, you 30can do so using the following procedure. (Note, this requires that 31your make program support VPATH. GNU's make will provide this 32functionality, for example.) If your make program does not support 33this, see the next section. 34 35For example, if you wish to store the binaries in ``tmpbuild`` build 36directory you might use the following procedure:: 37 38 mkdir /u1/tmpbuild 39 cd /u1/tmpbuild 40 /u1/krb5-VERSION/src/configure 41 make 42 43 44Building using lndir 45-------------------- 46 47If you wish to keep separate build directories for each platform, and 48you do not have access to a make program which supports VPATH, all is 49not lost. You can use the lndir program to create symbolic link trees 50in your build directory. 51 52For example, if you wish to create a build directory for solaris 53binaries you might use the following procedure:: 54 55 mkdir /u1/krb5-VERSION/solaris 56 cd /u1/krb5-VERSION/solaris 57 /u1/krb5-VERSION/src/util/lndir `pwd`/../src 58 ./configure 59 make 60 61You must give an absolute pathname to lndir because it has a bug that 62makes it fail for relative pathnames. Note that this version differs 63from the latest version as distributed and installed by the 64XConsortium with X11R6. Either version should be acceptable. 65 66 67Installing the binaries 68----------------------- 69 70Once you have built Kerberos, you should install the binaries. You can 71do this by running:: 72 73 make install 74 75If you want to install the binaries into a destination directory that 76is not their final destination, which may be convenient if you want to 77build a binary distribution to be deployed on multiple hosts, you may 78use:: 79 80 make install DESTDIR=/path/to/destdir 81 82This will install the binaries under *DESTDIR/PREFIX*, e.g., the user 83programs will install into *DESTDIR/PREFIX/bin*, the libraries into 84*DESTDIR/PREFIX/lib*, etc. *DESTDIR* must be an absolute path. 85 86Some implementations of make allow multiple commands to be run in 87parallel, for faster builds. We test our Makefiles in parallel builds 88with GNU make only; they may not be compatible with other parallel 89build implementations. 90 91 92Testing the build 93----------------- 94 95The Kerberos V5 distribution comes with built-in regression tests. To 96run them, simply type the following command while in the top-level 97build directory (i.e., the directory where you sent typed make to 98start building Kerberos; see :ref:`do_build`):: 99 100 make check 101 102On some operating systems, you have to run ``make install`` before 103running ``make check``, or the test suite will pick up installed 104versions of Kerberos libraries rather than the newly built ones. You 105can install into a prefix that isn't in the system library search 106path, though. Alternatively, you can configure with 107**-**\ **-disable-rpath**, which renders the build tree less suitable 108for installation, but allows testing without interference from 109previously installed libraries. 110 111There are additional regression tests available, which are not run 112by ``make check``. These tests require manual setup and teardown of 113support infrastructure which is not easily automated, or require 114excessive resources for ordinary use. The procedure for running 115the manual tests is documented at 116https://k5wiki.kerberos.org/wiki/Manual_Testing. 117 118 119Cleaning up the build 120--------------------- 121 122* Use ``make clean`` to remove all files generated by running make 123 command. 124* Use ``make distclean`` to remove all files generated by running 125 ./configure script. After running ``make distclean`` your source 126 tree (ideally) should look like the raw (just un-tarred) source 127 tree. 128 129Using autoconf 130-------------- 131 132(If you are not a developer, you can ignore this section.) 133 134In the Kerberos V5 source directory, there is a configure script which 135automatically determines the compilation environment and creates the 136proper Makefiles for a particular platform. This configure script is 137generated using autoconf, which you should already have installed if 138you will be making changes to ``src/configure.in``. 139 140Normal users will not need to worry about running autoconf; the 141distribution comes with the configure script already prebuilt. 142 143The autoconf package comes with a script called ``autoreconf`` that 144will automatically run ``autoconf`` and ``autoheader`` as needed. You 145should run ``autoreconf`` from the top source directory, e.g.:: 146 147 cd /u1/krb5-VERSION/src 148 autoreconf --verbose 149