diff options
Diffstat (limited to '')
| -rw-r--r-- | INSTALL | 368 | ||||
| -rw-r--r-- | INSTALL.REPO | 136 | ||||
| -rw-r--r-- | INSTALL.extra | 273 |
3 files changed, 777 insertions, 0 deletions
@@ -0,0 +1,368 @@ +Installation Instructions +************************* + + Copyright © 1994–1996, 1999–2002, 2004–2017, 2020–2023 Free Software +Foundation, Inc. + + Copying and distribution of this file, with or without modification, +are permitted in any medium without royalty provided the copyright +notice and this notice are preserved. This file is offered as-is, +without warranty of any kind. + +Basic Installation +================== + + Briefly, the shell command ‘./configure && make && make install’ +should configure, build, and install this package. The following +more-detailed instructions are generic; see the ‘README’ file for +instructions specific to this package. Some packages provide this +‘INSTALL’ file but do not implement all of the features documented +below. The lack of an optional feature in a given package is not +necessarily a bug. More recommendations for GNU packages can be found +in *note Makefile Conventions: (standards)Makefile Conventions. + + The ‘configure’ shell script attempts to guess correct values for +various system-dependent variables used during compilation. It uses +those values to create a ‘Makefile’ in each directory of the package. +It may also create one or more ‘.h’ files containing system-dependent +definitions. Finally, it creates a shell script ‘config.status’ that +you can run in the future to recreate the current configuration, and a +file ‘config.log’ containing compiler output (useful mainly for +debugging ‘configure’). + + It can also use an optional file (typically called ‘config.cache’ and +enabled with ‘--cache-file=config.cache’ or simply ‘-C’) that saves the +results of its tests to speed up reconfiguring. Caching is disabled by +default to prevent problems with accidental use of stale cache files. + + If you need to do unusual things to compile the package, please try +to figure out how ‘configure’ could check whether to do them, and mail +diffs or instructions to the address given in the ‘README’ so they can +be considered for the next release. If you are using the cache, and at +some point ‘config.cache’ contains results you don’t want to keep, you +may remove or edit it. + + The file ‘configure.ac’ (or ‘configure.in’) is used to create +‘configure’ by a program called ‘autoconf’. You need ‘configure.ac’ if +you want to change it or regenerate ‘configure’ using a newer version of +‘autoconf’. + + The simplest way to compile this package is: + + 1. ‘cd’ to the directory containing the package’s source code and type + ‘./configure’ to configure the package for your system. + + Running ‘configure’ might take a while. While running, it prints + some messages telling which features it is checking for. + + 2. Type ‘make’ to compile the package. + + 3. Optionally, type ‘make check’ to run any self-tests that come with + the package, generally using the just-built uninstalled binaries. + + 4. Type ‘make install’ to install the programs and any data files and + documentation. When installing into a prefix owned by root, it is + recommended that the package be configured and built as a regular + user, and only the ‘make install’ phase executed with root + privileges. + + 5. Optionally, type ‘make installcheck’ to repeat any self-tests, but + this time using the binaries in their final installed location. + This target does not install anything. Running this target as a + regular user, particularly if the prior ‘make install’ required + root privileges, verifies that the installation completed + correctly. + + 6. You can remove the program binaries and object files from the + source code directory by typing ‘make clean’. To also remove the + files that ‘configure’ created (so you can compile the package for + a different kind of computer), type ‘make distclean’. There is + also a ‘make maintainer-clean’ target, but that is intended mainly + for the package’s developers. If you use it, you may have to get + all sorts of other programs in order to regenerate files that came + with the distribution. + + 7. Often, you can also type ‘make uninstall’ to remove the installed + files again. In practice, not all packages have tested that + uninstallation works correctly, even though it is required by the + GNU Coding Standards. + + 8. Some packages, particularly those that use Automake, provide ‘make + distcheck’, which can by used by developers to test that all other + targets like ‘make install’ and ‘make uninstall’ work correctly. + This target is generally not run by end users. + +Compilers and Options +===================== + + Some systems require unusual options for compilation or linking that +the ‘configure’ script does not know about. Run ‘./configure --help’ +for details on some of the pertinent environment variables. + + You can give ‘configure’ initial values for configuration parameters +by setting variables in the command line or in the environment. Here is +an example: + + ./configure CC=c99 CFLAGS=-g LIBS=-lposix + + *Note Defining Variables::, for more details. + +Compiling For Multiple Architectures +==================================== + + You can compile the package for more than one kind of computer at the +same time, by placing the object files for each architecture in their +own directory. To do this, you can use GNU ‘make’. ‘cd’ to the +directory where you want the object files and executables to go and run +the ‘configure’ script. ‘configure’ automatically checks for the source +code in the directory that ‘configure’ is in and in ‘..’. This is known +as a “VPATH” build. + + With a non-GNU ‘make’, it is safer to compile the package for one +architecture at a time in the source code directory. After you have +installed the package for one architecture, use ‘make distclean’ before +reconfiguring for another architecture. + + On MacOS X 10.5 and later systems, you can create libraries and +executables that work on multiple system types—known as “fat” or +“universal” binaries—by specifying multiple ‘-arch’ options to the +compiler but only a single ‘-arch’ option to the preprocessor. Like +this: + + ./configure CC="gcc -arch i386 -arch x86_64 -arch ppc -arch ppc64" \ + CXX="g++ -arch i386 -arch x86_64 -arch ppc -arch ppc64" \ + CPP="gcc -E" CXXCPP="g++ -E" + + This is not guaranteed to produce working output in all cases, you +may have to build one architecture at a time and combine the results +using the ‘lipo’ tool if you have problems. + +Installation Names +================== + + By default, ‘make install’ installs the package’s commands under +‘/usr/local/bin’, include files under ‘/usr/local/include’, etc. You +can specify an installation prefix other than ‘/usr/local’ by giving +‘configure’ the option ‘--prefix=PREFIX’, where PREFIX must be an +absolute file name. + + You can specify separate installation prefixes for +architecture-specific files and architecture-independent files. If you +pass the option ‘--exec-prefix=PREFIX’ to ‘configure’, the package uses +PREFIX as the prefix for installing programs and libraries. +Documentation and other data files still use the regular prefix. + + In addition, if you use an unusual directory layout you can give +options like ‘--bindir=DIR’ to specify different values for particular +kinds of files. Run ‘configure --help’ for a list of the directories +you can set and what kinds of files go in them. In general, the default +for these options is expressed in terms of ‘${prefix}’, so that +specifying just ‘--prefix’ will affect all of the other directory +specifications that were not explicitly provided. + + The most portable way to affect installation locations is to pass the +correct locations to ‘configure’; however, many packages provide one or +both of the following shortcuts of passing variable assignments to the +‘make install’ command line to change installation locations without +having to reconfigure or recompile. + + The first method involves providing an override variable for each +affected directory. For example, ‘make install +prefix=/alternate/directory’ will choose an alternate location for all +directory configuration variables that were expressed in terms of +‘${prefix}’. Any directories that were specified during ‘configure’, +but not in terms of ‘${prefix}’, must each be overridden at install time +for the entire installation to be relocated. The approach of makefile +variable overrides for each directory variable is required by the GNU +Coding Standards, and ideally causes no recompilation. However, some +platforms have known limitations with the semantics of shared libraries +that end up requiring recompilation when using this method, particularly +noticeable in packages that use GNU Libtool. + + The second method involves providing the ‘DESTDIR’ variable. For +example, ‘make install DESTDIR=/alternate/directory’ will prepend +‘/alternate/directory’ before all installation names. The approach of +‘DESTDIR’ overrides is not required by the GNU Coding Standards, and +does not work on platforms that have drive letters. On the other hand, +it does better at avoiding recompilation issues, and works well even +when some directory options were not specified in terms of ‘${prefix}’ +at ‘configure’ time. + +Optional Features +================= + + If the package supports it, you can cause programs to be installed +with an extra prefix or suffix on their names by giving ‘configure’ the +option ‘--program-prefix=PREFIX’ or ‘--program-suffix=SUFFIX’. + + Some packages pay attention to ‘--enable-FEATURE’ options to +‘configure’, where FEATURE indicates an optional part of the package. +They may also pay attention to ‘--with-PACKAGE’ options, where PACKAGE +is something like ‘gnu-as’ or ‘x’ (for the X Window System). The +‘README’ should mention any ‘--enable-’ and ‘--with-’ options that the +package recognizes. + + For packages that use the X Window System, ‘configure’ can usually +find the X include and library files automatically, but if it doesn’t, +you can use the ‘configure’ options ‘--x-includes=DIR’ and +‘--x-libraries=DIR’ to specify their locations. + + Some packages offer the ability to configure how verbose the +execution of ‘make’ will be. For these packages, running ‘./configure +--enable-silent-rules’ sets the default to minimal output, which can be +overridden with ‘make V=1’; while running ‘./configure +--disable-silent-rules’ sets the default to verbose, which can be +overridden with ‘make V=0’. + +Particular systems +================== + + On HP-UX, the default C compiler is not ANSI C compatible. If GNU CC +is not installed, it is recommended to use the following options in +order to use an ANSI C compiler: + + ./configure CC="cc -Ae -D_XOPEN_SOURCE=500" + +and if that doesn’t work, install pre-built binaries of GCC for HP-UX. + + HP-UX ‘make’ updates targets which have the same timestamps as their +prerequisites, which makes it generally unusable when shipped generated +files such as ‘configure’ are involved. Use GNU ‘make’ instead. + + On OSF/1 a.k.a. Tru64, some versions of the default C compiler cannot +parse its ‘<wchar.h>’ header file. The option ‘-nodtk’ can be used as a +workaround. If GNU CC is not installed, it is therefore recommended to +try + + ./configure CC="cc" + +and if that doesn’t work, try + + ./configure CC="cc -nodtk" + + On Solaris, don’t put ‘/usr/ucb’ early in your ‘PATH’. This +directory contains several dysfunctional programs; working variants of +these programs are available in ‘/usr/bin’. So, if you need ‘/usr/ucb’ +in your ‘PATH’, put it _after_ ‘/usr/bin’. + + On Haiku, software installed for all users goes in ‘/boot/common’, +not ‘/usr/local’. It is recommended to use the following options: + + ./configure --prefix=/boot/common + +Specifying the System Type +========================== + + There may be some features ‘configure’ cannot figure out +automatically, but needs to determine by the type of machine the package +will run on. Usually, assuming the package is built to be run on the +_same_ architectures, ‘configure’ can figure that out, but if it prints +a message saying it cannot guess the machine type, give it the +‘--build=TYPE’ option. TYPE can either be a short name for the system +type, such as ‘sun4’, or a canonical name which has the form: + + CPU-COMPANY-SYSTEM + +where SYSTEM can have one of these forms: + + OS + KERNEL-OS + + See the file ‘config.sub’ for the possible values of each field. If +‘config.sub’ isn’t included in this package, then this package doesn’t +need to know the machine type. + + If you are _building_ compiler tools for cross-compiling, you should +use the option ‘--target=TYPE’ to select the type of system they will +produce code for. + + If you want to _use_ a cross compiler, that generates code for a +platform different from the build platform, you should specify the +“host” platform (i.e., that on which the generated programs will +eventually be run) with ‘--host=TYPE’. + +Sharing Defaults +================ + + If you want to set default values for ‘configure’ scripts to share, +you can create a site shell script called ‘config.site’ that gives +default values for variables like ‘CC’, ‘cache_file’, and ‘prefix’. +‘configure’ looks for ‘PREFIX/share/config.site’ if it exists, then +‘PREFIX/etc/config.site’ if it exists. Or, you can set the +‘CONFIG_SITE’ environment variable to the location of the site script. +A warning: not all ‘configure’ scripts look for a site script. + +Defining Variables +================== + + Variables not defined in a site shell script can be set in the +environment passed to ‘configure’. However, some packages may run +configure again during the build, and the customized values of these +variables may be lost. In order to avoid this problem, you should set +them in the ‘configure’ command line, using ‘VAR=value’. For example: + + ./configure CC=/usr/local2/bin/gcc + +causes the specified ‘gcc’ to be used as the C compiler (unless it is +overridden in the site shell script). + +Unfortunately, this technique does not work for ‘CONFIG_SHELL’ due to an +Autoconf limitation. Until the limitation is lifted, you can use this +workaround: + + CONFIG_SHELL=/bin/bash ./configure CONFIG_SHELL=/bin/bash + +‘configure’ Invocation +====================== + + ‘configure’ recognizes the following options to control how it +operates. + +‘--help’ +‘-h’ + Print a summary of all of the options to ‘configure’, and exit. + +‘--help=short’ +‘--help=recursive’ + Print a summary of the options unique to this package’s + ‘configure’, and exit. The ‘short’ variant lists options used only + in the top level, while the ‘recursive’ variant lists options also + present in any nested packages. + +‘--version’ +‘-V’ + Print the version of Autoconf used to generate the ‘configure’ + script, and exit. + +‘--cache-file=FILE’ + Enable the cache: use and save the results of the tests in FILE, + traditionally ‘config.cache’. FILE defaults to ‘/dev/null’ to + disable caching. + +‘--config-cache’ +‘-C’ + Alias for ‘--cache-file=config.cache’. + +‘--quiet’ +‘--silent’ +‘-q’ + Do not print messages saying which checks are being made. To + suppress all normal output, redirect it to ‘/dev/null’ (any error + messages will still be shown). + +‘--srcdir=DIR’ + Look for the package’s source code in directory DIR. Usually + ‘configure’ can determine that directory automatically. + +‘--prefix=DIR’ + Use DIR as the installation prefix. *note Installation Names:: for + more details, including other options available for fine-tuning the + installation locations. + +‘--no-create’ +‘-n’ + Run the configure checks, but stop before creating any output + files. + +‘configure’ also accepts some other, not widely useful, options. Run +‘configure --help’ for more details. diff --git a/INSTALL.REPO b/INSTALL.REPO new file mode 100644 index 0000000..c078359 --- /dev/null +++ b/INSTALL.REPO @@ -0,0 +1,136 @@ + Copyright 2013-2022 Free Software Foundation, Inc. + + Copying and distribution of this file, with or without + modification, are permitted in any medium without royalty provided + the copyright notice and this notice are preserved. + +This information supplements the generic installation instructions in +the file 'INSTALL'. It is meant for people building from the +development repository, rather than a distribution archive. +Distribution archives include a 'configure' script, among other files; +the repository does not. If you want to start building the 'groff' +system using an existing 'configure' script, you don't need the +information in this file. + +Dependencies +------------ + +The dependencies documented in the 'INSTALL.extra' file are required, as +are several others. + +* You will need Autoconf version 2.68 or higher and Automake version + 1.12.2 or higher. These requirements are asserted in the + 'bootstrap.conf' file. + + On operating systems supporting concurrent installation of multiple + versions of the GNU Autotools, set environment variables as in the + following example, adjusting the version numbers as required. + + $ export AUTOMAKE_VERSION=1.14 + $ export AUTOCONF_VERSION=2.69 + +* You will need a 'yacc' program. We recommend Berkeley yacc ('byacc') + or GNU Bison ('bison'). + +* groff's Texinfo manual is generated in several formats: GNU Info, + HTML, plain text, TeX DVI, and PDF. The former three require + 'makeinfo' from GNU Texinfo 5.0 or later. The latter two additionally + require a TeX installation, such as TeX Live. If TeX is not + installed, the DVI and PDF formats of the manual cannot be generated. + This will cause a build failure only if the Texinfo source file + "groff.texi" is updated and the make(1) "dist" or relevant file + targets are manually specified. + +* You will need the 'xpmtoppm', 'pnmdepth', and 'pnmtops' programs from + the Netpbm distribution. + + +Bootstrapping from a Git checkout +--------------------------------- + +Invoke the bootstrap script. + + $ ./bootstrap + + +What bootstrapping does +----------------------- + +The foregoing procedure will do two things: + + - clone the gnulib repository as a Git submodule in 'gnulib', add the + needed gnulib source files in 'lib' as well as required gnulib m4 + macros in 'gnulib_m4'; and + + - invoke 'autoreconf', which will call the GNU Autotools ('aclocal', + 'autoconf', 'automake') in the right order to create the following + files. + + -- INSTALL (a symlink to gnulib's INSTALL file) + -- Makefile.in + -- aclocal.m4 + -- autom4te.cache/ + -- build-aux/ (which contains all the helper scripts) + -- configure + -- src/include/config.hin + +'aclocal.m4' is a generated file; groff's m4 macros are included via the +'acinclude.m4' file. + + +Building +-------- + +You can now invoke the 'configure' script. It produces the +'config.status' script, which generates the Makefile. Then call 'make' +to build the groff project. You can do these from the source tree. + + $ ./configure + $ make # run with -j option if desired + +You can alternatively build groff outside of its source tree, which is +cleaner, leaving fewer files to confuse 'git status' if you aim to +undertake development. + + $ mkdir build + $ cd build + $ ../configure + $ make # run with -j option if desired + +A separate build tree need not be a subdirectory of the source. + + +Evaluation +---------- + +Several dozen sanity checks can be performed within the build tree. + + $ make check # run with -j option if desired + + +Installation +------------ + +When the build is finished you can install the groff build artifacts. + + $ make install install-doc # run with 'sudo' if necessary + + +Uninstalling +------------ + +See "Uninstalling" in the 'INSTALL.extra' file. + + +Rebuilding +---------- + +Start over from "Building" above. + + +##### Editor settings +Local Variables: +fill-column: 72 +mode: text +End: +# vim: set autoindent textwidth=72: diff --git a/INSTALL.extra b/INSTALL.extra new file mode 100644 index 0000000..78d4139 --- /dev/null +++ b/INSTALL.extra @@ -0,0 +1,273 @@ + Copyright 1997-2022 Free Software Foundation, Inc. + + Copying and distribution of this file, with or without modification, + are permitted in any medium without royalty provided the copyright + notice and this notice are preserved. + +This file contains information that supplements the generic +installation instructions in file 'INSTALL'. + + +Building and Installing from within the Source Tree +=================================================== + +A simple method of building and installing groff is as follows. + + 1. 'cd' to the directory containing groff's source code and type + './configure' to configure groff for your system. If you are + using 'csh' on an old version of AT&T Unix System V, you might need + to type 'sh ./configure' instead to prevent 'csh' from trying to + execute 'configure' itself. + + While 'configure' runs, it reports properties of the host system + that determine how the build is to be performed. + + 2. Type 'make' to compile groff. You may wish to add the '-j' option + to accelerate the build on multicore systems. + + 3. Optionally, check the build for sound operation as described under + "Evaluation" below. + + 4. Type 'sudo make install install-doc' to install groff's programs, + data files, and documentation. This is the only step for which you + need 'root' access; 'sudo' obtains this access. + + 5. You can remove the groff executables and other generated files from + the source code directory by typing 'make clean'. To also remove + the files that 'configure' created (so you can compile groff for a + different kind of computer or with different options to + 'configure'), type 'make distclean'. + + +Building and Installing from outside the Source Tree +==================================================== + +It is also possible to perform the build and installation procedure +outside the source code directory. In this case an external build +directory structure is created without changing any parts of the source +tree. This practice is useful if the source code is read-only or if +several different installations, such as for multiple architectures, +should be constructed. + +As an example, we will imagine that groff's source code is in +'/usr/local/src/groff' and that the build should happen within the +directory '/home/my/groff-build'. These directory names can be anything +valid on the operating system. + + 0. Create '/home/my/groff-build' and 'cd' to that directory. + + 1. Type '/usr/local/src/groff/configure' to configure groff for your + system. If you are using 'csh' on an old version of AT&T System V + Unix, you might need to type 'sh /usr/local/src/groff/configure' + instead. + + 2. Type 'make' to compile groff. You may wish to add the '-j' option + to accelerate the build on multicore systems. + + 3. Optionally, check the build for sound operation as described under + "Evaluation" below. + + 4. Type 'sudo make install install-doc' to install groff's programs, + data files, and documentation. This is the only step for which you + need 'root' access; 'sudo' obtains this access. + + 5. You can remove the groff executables and other generated files from + the source code directory by typing 'make clean'. To also remove + the files that 'configure' created (so you can compile groff for a + different kind of computer or with different options to + 'configure'), type 'make distclean'. + + +Unprivileged Installation +========================= + +The use of 'sudo' is necessary only if one or more destination +directories used by the 'make install' command are in locations that +require administrative access for writing. You can 'configure' groff +with options like '--prefix' that select an alternative directory that +is writable by the user conducting the build. Type './configure --help' +from the groff source tree for documentation of relevant options. +Running groff commands from such a directory may require you to set the +'GROFF_BIN_PATH', 'GROFF_FONT_PATH', and 'GROFF_TMAC_PATH' environment +variables. See the groff(1) man page. See "Evaluation" below for +instructions on viewing this man page without having groff installed. + + +Non-POSIX Platforms +=================== + +For instructions how to build groff with DJGPP tools for MS-DOS and +MS-Windows, see the file arch/djgpp/README. + +For instructions how to build groff with the MinGW tools for +MS-Windows, see the file README.MinGW. + + +Dependencies +============ + +groff is predominantly written in ISO C++98, so you need a C++ compiler +capable of handling this standardized version of the language. The C++ +source files use a suffix of '.cpp'; your C++ compiler must be able to +handle this. A C/C++ preprocessor that conforms to ISO C90 is also +required. If you don't already have a C++ compiler, we suggest GCC 9.4 +or later. To override the 'configure' script's choice of C++ compiler, +you can set the CXX environment variable to the name of its executable. + +A few components of groff are written in ISO C99. Features later made +optional by ISO C11 (the 'complex' primitive data type and +variable-length arrays) are not used. + +Several programs distributed with GNU roff are written in the Perl +language. Version 5.6.1 (1 April 2001) or later is required. + +The 'uchardet' library is an optional dependency of the 'preconv' +program: if this library is found by 'configure', it will be +automatically used by 'preconv'. Discovery of the 'uchardet' library +requires the 'pkg-config' program to be installed on your system, as +well as the library's C header files--on a package-based host system, +this can mean installing uchardet's '-dev' or '-devel' package. + +URW fonts +--------- + +The 'configure' script searches for PostScript Type 1 fonts originating +with the URW foundry; these are metrically compatible replacements for +the Adobe PostScript Level 2 base 35 fonts required by that standard. +These URW fonts are packaged with Ghostscript and in various derivative +versions. The Adobe fonts are not free software, but the replacements, +often named "Nimbus Roman", "Nimbus Sans", and "Nimbus Mono", and so +forth, are. The PostScript and early PDF standards assumed that these +base fonts would be supplied by the rendering device (a printer or PDF +viewer). Nowadays the PDF standard expects all fonts to be embedded in +the document; if groff's gropdf(1) output driver knows where to find +these fonts, you can use its "-e" option for this purpose. + +The build process populates "Foundry" and "download" files that tell +gropdf where to find their groff font descriptions and the font files +themselves, respectively. If you have multiple versions of the URW +fonts available on your system, or the 'configure' script cannot locate +them on its own, use its "--with-urw-fonts-dir" option to tell the +script where to find them. If you never use groff to generate +PostScript or PDF documents, you can ignore any output from the +'configure' script about URW fonts. + + +Miscellaneous +============= + +If you want A4 or U.S. letter paper format and the 'configure' script +produces an incorrect guess, say + + PAGE=xxx ./configure + +where 'xxx' should be either 'A4' or 'letter'. This affects only the +media size used by some groff output drivers, like grops (which can +still be overridden on the command line). For compatibility with AT&T +troff, GNU troff's default page length is always 11 inches. The page +length can be changed with the 'pl' request or with the "papersize" +macro package; see section "Paper format" in groff(1). + + +Evaluation +========== + +Once groff is built, you can check it for correct operation without +having to install it. groff comes with a test suite; use 'make check' +to run it. + +You can also try it out from the directory you used to build it. A +script called 'test-groff' is supplied for this purpose. It sets up +environment variables to allow groff to run without being installed. +For example, from the directory where you built groff, the command + + ./test-groff -t -man -Tascii src/roff/groff/groff.1 | less -R + +displays the groff(1) man page with the 'less' pager. (You might prefer +either the '-Tlatin1' or '-Tutf8' option to '-Tascii' depending on the +character set you're using.) + + +Documentation +============= + +The groff Texinfo manual can be viewed in several formats. Versions +corresponding to the source document 'doc/groff.texi' are supplied with +the source distribution archive. You can browse it in GNU info format. + + info doc/groff.info + +It can be viewed as text encoded in ISO Latin-1 as well. + + iconv -f latin1 -t utf8 doc/groff.txt | less # for UTF-8 users + less doc/groff.txt # for Latin-1 users + +Renderings in HTML, TeX DVI, and PDF are also available. + + lynx doc/groff.html + xdvi doc/groff.dvi + evince doc/groff.pdf + +A compilation of groff's man pages is available in text (with ISO 6429 +escape sequences) and PDF. + + less -R doc/groff-man-pages.utf8.txt + evince doc/groff-man-pages.pdf + + +In Case of Trouble +================== + +If a test fails, gather its log file from the build directory. For +instance, the test "tmac/tests/localization-works.sh" (in the source +directory) will have a log file called +"tmac/tests/localization-works.sh.log" in the build directory. + +To re-run a test, change to the top of the build directory (if +necessary) and run the test by name from the shell prompt. + +For example, to rerun the test mentioned above from a "build" directory +I created as a subdirectory in the source tree, I would do this. + + (cd build && ../tmac/tests/localization-works.sh) + +I can view the test log as follows. + + cat build/tmac/tests/localization-works.sh.log + +Many known issues are documented in the 'PROBLEMS' file; some apply to +historical systems. You can also browse groff bug reports via the GNU +Savannah issue tracker to see if your issue has already been reported. + + https://savannah.gnu.org/bugs/?group=groff + +If that doesn't help and you need support, please contact the groff +mailing list at groff@gnu.org. If you think that you have found a bug, +please submit a ticket using the 'BUG-REPORT' file as a template. + + https://savannah.gnu.org/bugs/?group=groff&func=additem + + +Uninstalling +============ + +If you are dissatisfied with groff, or to prepare for a new installation +from source, you can uninstall it to ensure that no stale files persist +on the system. Run the command 'sudo make uninstall'. (If you +successfully used 'make install', simply run 'make uninstall'.) At a +minimum, some directories not particular to groff, like 'bin' and +(depending on configuration) an X11 'app-defaults' directory will +remain, as will one plain file called 'dir', created by GNU Texinfo's +'install-info' command. (As of this writing, 'install-info' offers no +provision for removing an effectively empty 'dir' file, and groff does +not attempt to parse this file to determine whether it can be safely +removed.) All other groff artifacts will be deleted from the +installation hierarchy. + + +##### Editor settings +Local Variables: +fill-column: 72 +mode: text +End: +vim: set autoindent textwidth=72: |