Codebase list texlive-bin / debian/2016.20160409.40358-1 README.0overview
debian/2016.20160409.40358-1

Tree @debian/2016.20160409.40358-1 (Download .tar.gz)

README.0overview @debian/2016.20160409.40358-1raw · history · blame

(This file was generated by makeinfo and splitinfo.gawk.)
(Released under the old-style GNU documentation license;
 see sources or other output files for full text.)

2 Overview of build system
**************************

The TeX Live build system was redesigned in 2009, consistently using
Autoconf, Automake, and Libtool.  Thus
   'configure && make && make check && make install'
or the basically-equivalent top-level 'Build' script suffice to build
and install the TL programs.  The 'make check' clause performs various
tests of the generated programs--not strictly required but strongly
recommended.  Running 'configure --help' will display a comprehensive
list of all 'configure' options.

   The main components of the TL build system are:

'libs/LIB'
     Generic libraries.

'texk/LIB'
     TeX-specific libraries in subdirectories, notably LIB='kpathsea'.
     (The other one is 'texk/ptexenc'.)

'texk/PROG'
     TeX-specific programs (that use Kpathsea).

'utils/PROG'
     Other programs (that don't use Kpathsea).

   The primary design goal of the build system is modularity.  Each
program and library module (or package) specifies its own requirements
and properties, such as required libraries, whether an installed
(system) version of a library can be used, 'configure' options to be
seen at the top-level, and more.  An explicit list of all available
modules is kept in only one, central, place ('m4/kpse-pkgs.m4').

   A second, related goal is to configure and build each library before
configuring any other (program or library) module which uses that
library.  This allows checking for properties and features of a library
built as part of the TL tree in much the same way as for a system
version of that library.

   All generic libraries and several programs are maintained
independently.  The corresponding modules use (most of) the distributed
source tree and document any modifications of that source.

   All this is for the sake of simplifying both upgrading of modules
maintained independently and integrating new modules into the TL build
system.  (Not to say that either task is trivial.)