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
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
|
GNU `m4' is an implementation of the traditional Unix macro
processor. It is mostly SVR4 compatible, although it has some
extensions (for example, handling more than 9 positional parameters
to macros). `m4' also has builtin functions for including files,
running shell commands, doing arithmetic, etc. Autoconf needs GNU
`m4' for generating `configure' scripts, but not for running them.
GNU `m4' was originally written by Rene' Seindal, from Denmark.
GNU `m4' has a web site at http://www.gnu.org/software/m4/.
If GNU `m4' is meant to serve GNU `autoconf', beware that `m4'
should be fully installed *prior to* configuring `autoconf' itself.
Likewise, if you intend on hacking GNU `m4' from git, the bootstrap
process requires that you first install a released copy of GNU `m4'.
If you are just trying to build `m4' from a released tarball, you
should not normally need to run `./bootstrap' or `autoreconf'; just go
ahead and start with `./configure'. If you are trying to build `m4'
from git, more information can be found in the version-control-only
file HACKING.
In the subdirectories `tests' and `doc/examples' you will find various
m4 files, ranging from trivial test files to rather advanced macros. If
you intend to use m4 seriously, you might find useful material down
there.
See file `COPYING' for copying conditions. Note that M4 is distributed
under the GNU Public License version 3 or later. Some files in the
distribution are copied from the gnulib project, and hence bear the
designation version 2 or later because they are unmodified from gnulib;
however, if you modify these files using M4 rather than gnulib as the
source, you must update the license to be GPLv3 or later.
See file `INSTALL' for compilation and installation instructions.
See file `ABOUT-NLS' for how to customize this program to your language.
See file `NEWS' for a list of major changes in the current release.
See file `AUTHORS' for the names of maintainers.
See file `THANKS' for a list of contributors.
By using `./configure --with-gmp, you get multiple precision integral
and rational arithmetic using mpeval. The implementation depends on the
GNU gmp v2 library.
By using `./configure --with-modules=`foo bar baz', you get an m4 with only
the named modules preloaded. The default modules (preloaded if you do not
use this option) are sufficient to do the job of GNU m4-1.4. Additional
modules may be desirable, or necessary if libltdl does not support your
host architecture. The implementation uses libltdl interface, details of
which are in the libtool manual. See file `modules/README' for a more
detailed description.
By default, the `syscmd' and `esyscmd' macros try to use the first
instance of `sh' found by `command -p getconf PATH' at configure time,
with a default of `/bin/sh'. If that default is inappropriate, you
can use `./configure --with-syscmd-shell=location' to specify the
shell to use.
By using `./configure --with-dmalloc', GNU m4 is linked with Gray
Watson's dmalloc package. It is a debugging option for finding memory
management problems. Gray Watson's dmalloc package is available at
ftp://ftp.letters.com/src/dmalloc/dmalloc.tar.gz.
GNU M4 uses GNU Libtool in order to build shared libraries on a
variety of systems. While this is very nice for making usable
binaries, it can be a pain when trying to debug a program. For that
reason, compilation of shared libraries can be turned off by
specifying the `--disable-shared' option to `configure'. However,
without shared libraries, modules that are not preloaded will not be
available for use.
Send bug reports, comments or ideas to `bug-m4@gnu.org'. A bug report
is an adequate description of the problem: your input, what you
expected, what you got, and why this is wrong. Diffs are welcome, but
they only describe a solution, from which the problem might be uneasy to
infer. Don't forget all relevant information about your operating
system, compiler, libraries, ...
The easiest way to remember this information is by using the
testsuite. Any test failures are automatically logged, along with
lots of useful information about your setup; simply mailing
tests/testsuite.log to `bug-m4@gnu.org' is a good start. If you want
to dive in and debug a failure, you may find it useful to fine-tune
the execution of the testsuite. For example, running test 12 in
verbose mode can be done with:
make check TESTSUITEFLAGS='-v -d -x 12'
The testsuite understands --help to tell you more about the current
set of tests.
For any copyright year range specified as YYYY-ZZZZ in this package
note that the range specifies every single year in that closed interval.
========================================================================
Copyright (C) 2000, 2005-2011, 2013-2014, 2017 Free Software Foundation,
Inc.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
any later version published by the Free Software Foundation; with no
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
Texts. A copy of the license is included in the ``GNU Free
Documentation License'' file as part of this distribution.
|
