forked from TeX-Live/texlive-source
-
Notifications
You must be signed in to change notification settings - Fork 0
/
README.0overview
52 lines (40 loc) · 2.06 KB
/
README.0overview
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
(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 to consistently use
Autoconf, Automake, and Libtool. Thus, running
'configure && make && make check && make install'
or the essentially-equivalent top-level 'Build' script suffices 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 a single 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 and
integrating new modules into the TL build system. (Despite all efforts,
neither task is easy.)