texlive[44437] Build/source: README.* updates from tlbuild.texi
commits+karl at tug.org
commits+karl at tug.org
Sat May 20 01:03:48 CEST 2017
Revision: 44437
http://tug.org/svn/texlive?view=revision&revision=44437
Author: karl
Date: 2017-05-20 01:03:47 +0200 (Sat, 20 May 2017)
Log Message:
-----------
README.* updates from tlbuild.texi
Modified Paths:
--------------
trunk/Build/source/README.0overview
trunk/Build/source/README.1prerequisites
trunk/Build/source/README.2building
trunk/Build/source/README.4layout
trunk/Build/source/README.7coding
Modified: trunk/Build/source/README.0overview
===================================================================
--- trunk/Build/source/README.0overview 2017-05-19 22:21:26 UTC (rev 44436)
+++ trunk/Build/source/README.0overview 2017-05-19 23:03:47 UTC (rev 44437)
@@ -33,8 +33,8 @@
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').
+seen at the top level, and more. An explicit list of all available
+modules is kept in only one central place, namely '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
@@ -46,7 +46,7 @@
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.)
+ All this is for the sake of simplifying both upgrading of modules and
+integrating new modules into the TL build system. (Not to say that
+either task is trivial.)
Modified: trunk/Build/source/README.1prerequisites
===================================================================
--- trunk/Build/source/README.1prerequisites 2017-05-19 22:21:26 UTC (rev 44436)
+++ trunk/Build/source/README.1prerequisites 2017-05-19 23:03:47 UTC (rev 44437)
@@ -10,13 +10,17 @@
(If 'make' from your 'PATH' is not GNU make, you can set 'MAKE' in the
environment to whatever is necessary.)
- Indeed, GNU 'make' is required only because of some third-party
-libraries, notably FreeType; all the TL-maintained directories (and
+ GNU 'make' is required only because of some third-party libraries,
+notably FreeType; all the TL-maintained directories (and
Automake/Autoconf output in general) should work with any reasonable
'make'.
However, a few programs in the tree have additional requirements:
+'dvisvgm'
+ requires a C++11 compiler, such as gcc 4.8.1 (or later) or clang
+ 3.3 (or later).
+
'web2c'
requires 'perl' for some tests run by 'make check'.
Modified: trunk/Build/source/README.2building
===================================================================
--- trunk/Build/source/README.2building 2017-05-19 22:21:26 UTC (rev 44436)
+++ trunk/Build/source/README.2building 2017-05-19 23:03:47 UTC (rev 44437)
@@ -47,7 +47,7 @@
If configuring or building a module fails, you should first find and fix
the problem, then perhaps remove the subdirectory for that module from
-the build tree, and finally rerun the top-level 'make' (or 'Build' with
+the build tree, and finally rerun the top level 'make' (or 'Build' with
'--no-clean' as its first argument).
4.3 Build in parallel
@@ -65,7 +65,7 @@
4.4 Build distribution
======================
-Running 'make dist' at the top-level creates a tarball
+Running 'make dist' at the top level creates a tarball
'tex-live-YYYY-MM-DD.tar.xz' from the TL source tree. Running 'make
distcheck' also verifies that this tarball suffices to build and install
all of TL.
@@ -128,28 +128,24 @@
things are working. There are many 'configure' options you can tweak as
desired; check the output from 'configure --help'.
- Finally, the above retrieves the entire TL source tree (some 300mb).
-It is natural to ask if this is really necessary. Strictly speaking,
-the answer is no, but it is vastly more convenient to do so. If you cut
-down the source tree, you must also give additional 'configure' flags to
-individually disable using system versions of libraries, or the
-intricacies of the dependencies (such as 'teckit' requiring 'zlib') will
-have undesired side effects. For an example, see the 'build-pdftex.sh'
-script in the 'pdftex' development sources (<http://pdftex.org>), which
-are indeed a cut-down TL source tree.
+ Finally, the above retrieves the entire TL source tree (several
+hundred megabytes). It is natural to ask if this is really necessary.
+Strictly speaking, the answer is no, but it is vastly more convenient to
+do so. If you cut down the source tree, you must also give additional
+'configure' flags to individually disable using system versions of
+libraries, or the intricacies of the dependencies (such as 'teckit'
+requiring 'zlib') will have undesired side effects. For an example, see
+the 'build-pdftex.sh' script in the 'pdftex' development source
+(<http://pdftex.org>), which is indeed a cut-down TL source tree.
- Caveat 1: even with '--disable-all-pkgs', dependencies will be
-checked. For instance, if a non-MacOSX system does not have
-'fontconfig', XeTeX cannot be built (*note Prerequisites::) and
-'configure' will terminate. To proceed without such dependencies,
-specify '--enable-missing' also. (Arguably this should happen
-automatically.)
+ Even with '--disable-all-pkgs', dependencies will be checked. For
+instance, if a non-MacOSX system does not have 'fontconfig', XeTeX
+cannot be built (*note Prerequisites::) and 'configure' will terminate.
+To proceed without such dependencies, specify '--enable-missing' also.
+(Arguably this should happen automatically.)
- Caveat 2: unless 'CC' and 'CXX' and 'OBJCXX' are explicitly
-specified, each package will configure its own compiler(s). In
-practice, this results in a conflict in only one instance: the ICU
-('libs/icu') library will prefer 'clang' and 'clang++' over all others
-if they are installed, whereas everything else prefers 'gcc' and 'g++'.
-Usually the results will be interoperable, but it can cause extra
-confusion and problems when debugging a program that uses ICU.
+ By default, the 'gcc' compilers will be used if present; otherwise,
+individual packages may use something different. You can explicitly
+specify the compilers to be used with the environment variables 'CC',
+'CXX', and 'OBJCXX'.
Modified: trunk/Build/source/README.4layout
===================================================================
--- trunk/Build/source/README.4layout 2017-05-19 22:21:26 UTC (rev 44436)
+++ trunk/Build/source/README.4layout 2017-05-19 23:03:47 UTC (rev 44437)
@@ -32,7 +32,7 @@
bison (GNU Bison) 3.0.4
flex 2.6.0
ltmain.sh (GNU libtool) 2.4.6
- m4 (GNU M4) 1.4.17
+ m4 (GNU M4) 1.4.18
makeinfo (GNU texinfo) 6.1
These versions should be used to update the generated files (e.g.,
@@ -63,11 +63,11 @@
libraries), 'utils/' (additional programs), and 'libs/' (generic
libraries).
- The top-level directories 'am/' and 'm4/' contain 'Makefile.am'
-fragments and Autoconf macros, respectively, used in many places.
-Specifically, the file 'm4/kpse-pkgs.m4' contains lists of all program
-and library modules; missing modules are silently ignored. (This helps
-in creating cut-down source trees.)
+ In addition, the top-level directories 'am/' and 'm4/' contain
+'Makefile.am' fragments and Autoconf macros, respectively, used in many
+places. Specifically, the file 'm4/kpse-pkgs.m4' contains lists of all
+program and library modules; missing modules are silently ignored.
+(This helps in creating cut-down source trees.)
Each module contributes fragments (in separate files) defining its
capabilities and requirements to the 'configure.ac' scripts at the
@@ -80,18 +80,24 @@
'distcheck'.
The top-level 'build-aux/' directory contains the common files
-'compile', 'config.guess', 'config.sub', 'depcomp', etc. for most
-packages, pulled from the GNU Gnulib sources
+'compile', 'config.guess', 'config.sub', 'depcomp', etc. used by most
+packages. These are from the GNU Gnulib sources
(<http://www.gnu.org/software/gnulib>), which in turn synchronizes with
the appropriate ultimate upstream repository. There are, however,
independent copies in, e.g., 'libs/freetype2/freetype-*/builds/unix/',
-and similar places. The 'reautoconf' script does not touch those, but a
-TL cron job keeps them in sync (nightly).
+and a few other places. The 'reautoconf' script does not touch those,
+but a TL cron job keeps them in sync (nightly).
The directory 'extra/' contains things which are not part of the TL
-build, but are present just for (someone's) convenience, e.g.,
-'epstopdf' which is developed here.
+build, but are present just for (someone's) convenience, e.g., is
+'epstopdf' development source is here.
+ When the top-level './Build' script is used to build TL, two more two
+more top-level directories appear: 'Work/' for the build tree, and
+'inst/' for the install tree (from 'make install'). These names (and
+everything else about 'Build''s operation) can be changed by setting
+environment variables before running it; see the script file.
+
6.3 Autoconf macros
===================
@@ -278,9 +284,8 @@
----------------------------------------
This generic library uses the source tree in, e.g., the subdirectory
-'libpng-1.6.16' with all modifications for TL recorded in
-'libpng-1.6.16-PATCHES/*'. The 'configure.ac' fragment
-'ac/withenable.ac' contains
+'libpng-src/' with all modifications for TL recorded in 'TLpatches/*'.
+The 'configure.ac' fragment 'ac/withenable.ac' contains
KPSE_WITH_LIB([libpng], [zlib])
@@ -377,9 +382,9 @@
6.5.1 The 't1utils' package in 'utils/t1utils'
----------------------------------------------
-Once again we use the distributed source tree 't1utils-1.39' with
-modifications documented in 't1utils-1.39-PATCHES/*' and a proxy build
-system consisting of 'configure.ac' and 'Makefile.am'. The fragment
+Once again we use the distributed source tree 't1utils-src' with
+modifications documented in 'TLpatches/*' and a proxy build system
+consisting of 'configure.ac' and 'Makefile.am'. The fragment
'ac/withenable.ac' contains
KPSE_ENABLE_PROG([t1utils])
@@ -390,12 +395,11 @@
6.5.2 The 'xindy' package in 'utils/xindy'
------------------------------------------
-This module uses the distributed source tree 'xindy-2.5.1' with
-modifications documented in 'xindy-2.5.1-PATCHES/*', a proxy
-'configure.ac', and a wrapper 'Makefile.am' that descends into
-'xindy-2.5.1'. The 'xindy' build requires that the distributed
-'Makefile's allow a 'VPATH' build, can handle all targets, and do not
-refer to '${top_srcdir}' or '${top_builddir}'. The fragment
+This module uses the distributed source tree 'xindy-src/' with
+modifications documented in 'TLpatches/*', a proxy 'configure.ac', and a
+wrapper 'Makefile.am' that descends into 'xindy-src'. The 'xindy' build
+requires a 'make' that supports a 'VPATH' build, can handle all targets,
+and do not refer to '${top_srcdir}' or '${top_builddir}'. The fragment
'ac/withenable.ac' contains
KPSE_ENABLE_PROG([xindy], , [disable native])
@@ -446,6 +450,13 @@
This section outlines the basic process for adding new packages to the
TL build system.
+ In any case, a new package directory 'foo' should contain the
+original sources, as modified for TL, in 'foo/foo-src', and the changes
+should be documented in 'foo/TLpatches/*'; changes should also be
+submitted upstream whenever reasonable, of course. In addition, 'foo/'
+will need the usual Automake build-related files ('configure.ac',
+'Makefile.am', etc. Please keep a 'ChangeLog' for all TL changes.
+
6.6.1 Adding a new program module
---------------------------------
Modified: trunk/Build/source/README.7coding
===================================================================
--- trunk/Build/source/README.7coding 2017-05-19 22:21:26 UTC (rev 44436)
+++ trunk/Build/source/README.7coding 2017-05-19 23:03:47 UTC (rev 44437)
@@ -10,8 +10,9 @@
considerable efforts into that direction we are still far from that goal
and there are reasons that we may never fully reach it. Below are some
rules about declarations of functions or variables and the use of
-'const'. These rules should be applied to all parts of the TeX Live
-tree, except some of those maintained independently.
+'const'. These rules should be applied to most of the TeX Live tree,
+the exception being code that is maintained independently and whose
+maintainers don't want to accept patches.
9.1 Declarations and definitions
================================
More information about the tex-live-commits
mailing list