| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
Some versions of lex need you to forward-declare yywrap in a %{ %}
block before the rules section, if you’re going to define it yourself.
May help with bug #110312.
* lib/autoconf/programs.m4 (_AC_PROG_LEX_YYTEXT_DECL): In the test
input to lex, forward-declare yywrap before the rules.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 29ede6b96feee29c0c477d1659081bbdb82cd8b3 caused AC_PROG_LEX to
stop looking for a library that provides yywrap. This broke several
packages in a Debian archive rebuild.
Revert all the way to the 2.69 behavior, which was to set LEXLIB to
-ll or -lfl if that library defines yywrap, but allow AC_PROG_LEX to
succeed if neither -ll nor -lfl exists on the system, even if a lex
program that doesn't define yywrap would need it.
(This behavior was a bug, but people have come to depend on it.
See https://savannah.gnu.org/support/index.php?110269 and the
thread starting from
https://lists.gnu.org/r/autoconf-patches/2020-07/msg00013.html
for gory details.)
To provide a path away from bug-compatibility, AC_PROG_LEX now takes
one argument, documented as a whitespace-separated list of options.
Two options are defined: ‘yywrap’ means to look for yywrap and behave
as if lex is unavailable if it isn’t found; ‘noyywrap’ means to not
look for yywrap at all. These are mutually exclusive.
Fixes bug #110346.
* lib/autoconf/programs.m4 (AC_PROG_LEX): Add an argument which
can be either ‘yywrap’, meaning to look for yywrap in -ll, or
‘noyywrap’, meaning to not look for yywrap at all. In the
absence of either option, issue an obsoletion warning and
revert to behavior bug-compatible with 2.69.
* tests/semantics.at: Add more tests of AC_PROG_LEX.
* tests/mktests.sh: Exclude AC_PROG_LEX from autogenerated tests.
* doc/autoconf.texi: Update documentation of AC_PROG_LEX.
* NEWS: Update notes on AC_PROG_LEX.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some of the compiler options that AC_OPENMP tests, mean “enable
OpenMP” to one compiler, but “write output to a file named ‘mp’ or
‘penmp’” to other compilers. The author of AC_OPENMP believed that
this could only happen if compilation was *successful*, but didn’t
realize that one of the options means “write *preprocessed* output to
a file named ‘penmp’” to SunPRO C, and that this *would* succeed on
the test program. (AC_LINK_IFELSE fails anyway, because the
compilation didn’t create conftest$exeext.)
The option that actually means “enable OpenMP” to SunPRO C is earlier
in the list than the option that means “write preprocessed output to a
file named ‘penmp’”, so we might never have noticed this, but for a
second bug: if you have a bad combination of Solaris operating system
patches installed, it’s possible for this compiler to
successfully *compile* a program that uses OpenMP, but then fail
to *link* it because the OpenMP runtime library is out of sync with
the core C library. AC_OPENMP doesn’t distinguish this case from
“that option doesn’t mean ‘enable OpenMP’” so it goes on to other
entries in the list and hits the “write preprocessed output” one.
Implement four layers of defensive measures against this mess:
- Use an #error directive instead of a compile-time syntax error
to halt compilation when _OPENMP is not defined.
- For each option that might mean “enable OpenMP”, first do an
AC_COMPILE_IFELSE to find out whether it really means that, and
then an AC_LINK_IFELSE to find out whether it works. If the
compilation succeeds but the link fails, bail out of the loop and
declare OpenMP to be unsupported.
- If a file named ‘mp’ or ‘openmp’ exists in configure’s working
directory when AC_OPENMP begins, error out. This means it is safe
to delete any file named ‘mp’ or ‘openmp’ that exists at the *end*
of AC_OPENMP.
- If a file named ‘mp’ or ‘openmp’ exists in the top level of the
source tree with a configure.ac that uses AC_OPENMP, have autoconf
error out, too.
Fixes bug #110353. Problem reported by Dagobert Michelsen.
* lib/autoconf/c.m4 (_AC_LANG_OPENMP(C)): Change ‘choke me’ to
‘#error "OpenMP not supported"’.
(AC_OPENMP): AC_REQUIRE _AC_OPENMP_SAFE_WD. For each option, do
both a compile test and a link test; if the compile test succeeds
but the link fails, don’t go on to other candidate options.
Delete files named ‘mp’ and ‘penmp’ after the loop.
(_AC_OPENMP_SAFE_WD): New macro, subroutine of AC_OPENMP. If files
named ‘mp’ or ‘penmp’ exist, error out both at autoconf time and at
configure time.
* tests/torture.at (Files clobbered by AC_OPENMP): New test.
* doc/autoconf.texi: Document requirement not to have files
named ‘mp’ or ‘penmp’ next to a configure.ac that uses AC_OPENMP.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 326c9a547423d25c621bc5c0ef76edbf6eda8c92 introduced a custom
AC_LANG_CALL for C++. Jani Välimaa reports in
https://lists.gnu.org/archive/html/bug-autoconf/2020-10/msg00054.html
that the new code does not handle AC_CHECK_LIB([foo], [main])
correctly. This is not the recommended way to use AC_CHECK_LIB, but
it’s what you get if you autoupdate from AC_HAVE_LIBRARY, and some
people may not have bothered replacing main with a more appropriate
symbol.
This patch changes the return type of the fake function declaration
for AC_CHECK_LIB’s second argument to be ‘int’, which is sufficient to
make g++ 10.2.0 happy again. We’re still on thin ice, unfortunately;
the code generated by AC_LANG_CALL *always* has undefined behavior, in
both C and C++, unless by chance the real prototype of the function
we’re probing for happens to match our fake declaration. The only
permanent cure is to stop faking declarations, and that’s going to be
a challenge.
* lib/autoconf/c.m4 (AC_LANG_CALL(C++)): Use ‘int’ for the return
type of the fake function declaration, to avoid problems when
the function whose declaration we’re faking is ‘main’.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is undesirable because X11 development headers and libraries
found by searching /usr are much more likely to belong to the build
operating system than the host operating system (being cross-compiled
for). A particularly problematic case, from the original bug report,
is “using a sysroot where the target is binary compatible with the
host. In this case AC_PATH_X will happily look at /usr and say that
yes, X is available, even if the sysroot doesn't have X.”
To cross-compile X client applications, the recommended procedure is
to put X11 headers and libraries for the host system in the cross
compiler’s default search path; alternatively, --x-includes and
--x-libraries can be used.
Fixes bug #110345. Problem reported by Ross Burton.
* lib/autoconf/libs.m4 (_AC_PATH_X): Before doing anything else,
see whether a test compilation with no special options (just -lX11)
will work. If it doesn’t, only invoke _AC_PATH_X_XMKMF and
_AC_PATH_X_DIRECT when not cross compiling.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In most cases, checks depending on the value of $host_os should
treat *-*-cygwin*, *-*-msys*, and *-*-mingw* all the same.
* lib/autoconf/fortran.m4 (_AC_FC_LIBRARY_LDFLAGS):
Discard -lkernel32 on msys* as well.
When not discarding -lkernel32, deduplicate it, like other -l options.
* lib/autoconf/functions.m4 (AC_FUNC_MALLOC, AC_FUNC_REALLOC):
msys* also guarantee to return nonnull for malloc(0)/realloc(0).
* tests/local.at (at_check_env): Also ignore MSYS as an environment
variable.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make ‘autoreconf --install’ add config.sub, config.guess, and
install-sh to the source tree when necessary. This is only relevant
for packages that don’t use Automake, because ‘automake --add-missing’
already adds these scripts to the source tree, but apparently there
are plenty of packages out there that don’t use Automake, didn’t need
config.{sub,guess} with autoconf 2.69, and do need them with 2.70.
Such packages will need to have their equivalent of ‘make dist’
manually updated to ship the new files, of course.
This patch also has ‘autoreconf’ issue an error if aux files are
missing and ‘--install’ *wasn’t* used, or if --install *was* used but
could not install all the missing files. This error is more likely to
be caught by maintainers than the configure-time error added in the
previous patch. It is not currently practical to make autoconf itself
issue this error message, because of how the autoconf wrapper script
is different from all the other wrapper scripts. Also, autoreconf
runs automake *after* autoconf, so we’d get spurious errors from
packages that do use automake.
* bin/autoreconf.in ($buildauxdir): New package global, initialized
to $pkgdatadir/build-aux, or to $ENV{autom4te_buildauxdir} if that’s set.
(find_missing_aux_files, can_install_aux_files, try_install_aux_files)
(install_aux_file, make_executable): New subs.
(autoreconf_current_directory): Trace AC_REQUIRE_AUX_FILE.
After running all tools that might install aux files, try to
install aux files ourself if --install was given.
After that, report on any that are still missing.
* lib/autom4te.in (Autoreconf-preselections): Add AC_REQUIRE_AUX_FILE.
Make list order consistent with list order in autoreconf.in.
* tests/wrapper.as: Set autom4te_buildauxdir to point to location of
config.guess, config.sub, and install-sh within the source tree.
* lib/local.mk: Install config.guess, config.sub, and install-sh
into $(pkgdatadir)/build-aux.
* doc/autoconf.texi: Document that autoreconf can now install
config.guess, config.sub, and install-sh itself without help from
automake, but packages not using automake will need to arrange for
tarball distribution of these files by hand.
* tests/torture.at (Missing auxiliary files): Test autoreconf as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Another regression identified by the Debian archive rebuild was that
more macros require the presence of config.sub and config.guess now.
‘autoreconf --install’ doesn’t install these itself, it relies on
‘automake --add-missing’ to do that; so, packages that don’t use
Automake will fail at the configure stage after configure is
regenerated. To make matters worse, AC_CONFIG_AUX_DIRS assumes that
everyone who needs config.sub and config.guess also needs install-sh,
so in about half of the affected packages, the failure manifested as a
complaint about install-sh being missing -- technically true but
adding install-sh wouldn’t have resolved the problem by itself.
This patch overhauls the AC_CONFIG_AUX_DIR(S) mechanism so that a
configure script knows the complete set of aux scripts that were
AC_REQUIRE_AUX_FILE’d for it, checks for the existence of all of
them, and not any others. Thus, this configure script
AC_INIT([test], [1.0])
AC_FUNC_MALLOC
AC_CONFIG_HEADERS([config.h])
AC_OUTPUT
will work fine in a directory that contains config.sub and
config.guess but not install-sh. Also, if it’s in a directory
that *doesn’t* contain config.sub and config.guess, it will print an
accurate error message
configure: error: cannot find required auxiliary files: config.guess config.sub
instead of the misleading
configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."
A side-effect: it doesn’t make sense for AC_CONFIG_SUBDIRS to demand
the presence of Cygnus configure in the aux dir, on the off-chance
that one of the subdirectories *might* be using it -- I have no idea
where someone would even get a copy of that nowadays -- so I dropped
that feature. I rather suspect nobody has needed it in over a decade.
I also documented the expanded need for config.sub and config.guess in
NEWS as well as the manual.
* NEWS: Document expanded need for config.sub and config.guess.
Document removed support for Cygnus configure in subdirectories.
* doc/autoconf.texi: Clarify exactly when install-sh, config.sub,
and/or config.guess are required. Document canonical online sources
for these scripts. Revise documentation of AC_CONFIG_AUX_DIR and
AC_REQUIRE_AUX_FILE. Minor improvements to documentation of
AC_CONFIG_SRCDIR. Remove mentions of Cygnus configure in
subdirectories.
* lib/autoconf/general.m4
(_AC_INIT_PARSE_ARGS): Remove mention of Cygnus configure;
clarify function of configure.gnu.
(AC_CONFIG_AUX_DIR): Support multiple invocations.
(AC_CONFIG_AUX_DIRS): Now an undocumented compatibility interface
rather than an internal subroutine; just runs AC_CONFIG_AUX_DIR on
each of its arguments.
(AC_CONFIG_AUX_DIR_DEFAULT): Now a backward compatibility stub that
requires _AC_INIT_AUX_DIR without adding anything to _AC_AUX_FILES.
(AC_REQUIRE_AUX_FILE): Now adds the named aux file to _AC_AUX_FILES
and requires _AC_INIT_AUX_DIR, as well as being a trace hook.
(_AC_INIT_AUX_DIR): New home of the loop searching for necessary aux
files (formerly in AC_CONFIG_AUX_DIRS). Looks for all the necessary
aux files, not just for install-sh.
(ac_config_guess, ac_config_sub, ac_configure): Issue deprecation
warnings if these undocumented shell variables are actually used.
(AC_CANONICAL_BUILD, AC_CANONICAL_HOST, AC_CANONICAL_TARGET):
No need to require AC_CONFIG_AUX_DIR_DEFAULT.
Can rely on $ac_aux_dir ending with a slash.
* lib/autoconf/programs.m4 (AC_PROG_INSTALL, AC_PROG_MKDIR_P):
No need to require AC_CONFIG_AUX_DIR_DEFAULT.
* lib/autoconf/status.m4 (_AC_CONFIG_SUBDIRS):
No need to require AC_CONFIG_AUX_DIR_DEFAULT.
Remove check for Cygnus configure; clarify function of configure.gnu.
* lib/autotest/general.m4: Remove mention of Cygnus configure.
* tests/torture.at (Missing auxiliary files): New test.
|
|
|
|
|
|
|
|
|
| |
The construct _AS_PATH_WALK was using to conditionally execute its
IF-NOT-FOUND argument, was a little too fragile: relatively natural
variations in usage, such as putting the final `])` on a line by
itself, could cause shell syntax errors. Use AS_IF instead.
* lib/m4sugar/m4sh.m4: Use AS_IF to execute IF-NOT-FOUND conditionally.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Debian project has done an archive rebuild using autoconf 2.69c,
which found several serious regressions from 2.69 where test programs
used to be accepted by a C++ compiler, but are now rejected. Part of
the problem is that newer C++ compilers are more likely to reject
“traditional” sloppy C, but part of it is that bug fixes since 2.69
did not consider the possibility of test macros being used with
AC_LANG([C++]) in effect.
I’m still working on test suite improvements that will catch these
regressions in the future, but I don’t see any reason to delay the
actual bugfixes. (I’ve gotten far enough on the test suite changes
that I know they _will_ catch the bugs.)
* NEWS: Document that AC_FUNC_STRERROR_R no longer tries to detect a
strerror_r that exists in the C library but isn’t declared by string.h.
* lib/autoconf/c.m4
(AC_LANG_CALL(C++)): New macro. Use a more robust technique for
avoiding a type conflict with any intrinsic prototype.
(AC_LANG_CALL(C)): Remove #ifdef __cplusplus, this macro is no longer
used to generate C++ code.
* lib/autoconf/functions.m4
(AC_FUNC_CLOSEDIR_VOID): Rely on <dirent.h> to declare closedir.
Simplify test program. Use AC_COMPILE_IFELSE, not AC_RUN_IFELSE.
(_AC_FUNC_MALLOC_IF, _AC_FUNC_REALLOC_IF): Use void *, not char *,
for variable holding a value returned by malloc/realloc respectively.
(AC_FUNC_STRERROR_R): Don’t AC_CHECK_FUNCS_ONCE strerror_r.
AC_DEFINE HAVE_STRERROR_R if and only if we are also going to define
HAVE_DECL_STRERROR_R. Remove AC_RUN_IFELSE fallback when strerror_r
is not declared.
* lib/autoconf/headers.m4 (AC_USG): Use "", not 0, for the first
argument to rindex.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AC_DIAGNOSE is used in several extremely popular add-on macros,
notably AM_INIT_AUTOMAKE, AM_GNU_GETTEXT, and AC_LIBTOOL_DLOPEN.
Until newer versions of these macros are available, -Wobsolete
warnings for AC_DIAGNOSE will be unhelpful noise.
Therefore, make it so AC_DIAGNOSE(...) will still be replaced with
m4_warn(...) by autoupdate, but autoconf runs will not complain about
AC_DIAGNOSE. The bulk of the patch is augmenting AU_DEFUN so that it
can define a “silent” autoupdate replacement, and documenting the new
feature.
* lib/autoconf/autoupdate.m4 (AU_DEFUN): Add a fourth argument, SILENT,
which must be either empty or the word ‘silent’. If it is ‘silent’,
the macro being defined will *not* issue a -Wobsolete warning when
expanded by autoconf.
Tweak quotation to prevent emacs’ parenthesis matching from getting
confused.
(AU_ALIAS): Add the SILENT argument here as well.
* lib/autoconf/general.m4 (AC_DIAGNOSE): Define as a silent AU_DEFUN.
Add commentary explaining why this was done and when it can be
changed back.
* doc/autoconf.texi (AU_DEFUN, AU_ALIAS): Revise; document new SILENT
argument.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several autotools programs use ‘do’ to evaluate Perl code
generated into a file in the temporary directory created by
Autom4te::General::mktmpdir. If the environment variable
TMPDIR is a relative path, mktmpdir will set $tmp to a
relative path and we’ll end up trying to ‘do’ a relative
path, which searches for the file in @INC. This doesn’t
work under perl 5.26 or later, because ‘.’ was removed
from @INC in that version (for security reasons).
Ensure that mktmpdir sets $tmp to an absolute pathname.
Also use File::Temp::tempdir to create the temporary
directory, instead of shelling out to ‘mktemp -d’;
this eliminates a subprocess and means we don’t have
to worry about cleaning up the directory on exit.
Problem found by Kent Fredric and reported as
<https://bugs.gentoo.org/625576>.
Supersedes Gentoo’s autoconf-2.69-perl-5.26-2.patch.
* lib/Autom4te/General.pm
(mktmpdir): Use File::Temp to create temporary directory.
Ensure that $tmp is an absolute path.
(END): No need to clean up $tmp.
* tests/tools.at (autotools and relative TMPDIR): New test.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While working on the previous patches I noticed that all of these
macros are officially obsolete, but autoupdate doesn’t replace them.
_AC_COMPUTE_INT is easy to autoupdate. AC_{DIAGNOSE,FATAL,WARNING}
require a little special handling because their replacements are
m4sugar macros, and autoupdate normally expands m4sugar macros as it
goes. Fortunately, the same workaround as is used for AC_FOREACH can
be applied. AC_OBSOLETE also needs that workaround, and cannot be
fully replaced automatically.
The bulk of the patch is removing internal uses of AC_DIAGNOSE.
* lib/autoconf/autoupdate.m4
* lib/autoconf/c.m4
* lib/autoconf/functions.m4
* lib/autoconf/general.m4
* lib/autoconf/headers.m4
* lib/autoconf/lang.m4
* lib/autoconf/status.m4
* lib/autoconf/types.m4
* tests/local.at
* tests/tools.at:
Use, and/or refer to, m4_warn instead of AC_DIAGNOSE.
* lib/autoconf/general.m4 (_AC_COMPUTE_INT): Define using AU_DEFUN.
(AC_DIAGNOSE, AC_FATAL, AC_WARNING): Autoupdate to m4_warn,
m4_fatal, and m4_warn([syntax], [$1]) respectively, using the same
paired AU_DEFUN/AC_DEFUN trick that is used for AC_FOREACH.
(AC_OBSOLETE): Autoupdate to m4_warn([obsolete], [$1]) and advise
hand-conversion to AU_DEFUN.
* lib/autoconf/autoupdate.m4 (AU_DEFUN): Tweak quoting so m4_warn([$3])
is emitted into the edited configure.ac instead of being expanded at
autoupdate time.
* tests/tools.at (autoupdating AC_FOREACH): Adjust grep expressions.
(autoupdating AC_DIAGNOSE and AC_WARNING): New test.
(autoupdating AC_FATAL): New test.
(autoupdating AC_OBSOLETE): New test.
* tests/mktests.sh (ac_exclude_list, au_exclude_list):
Exclude AC_DIAGNOSE, AC_FATAL, AC_FOREACH, AC_OBSOLETE, and AC_WARNING
if not already excluded.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
autoheader and autoscan both run autoconf in trace mode, and
autoheader makes a point of passing down the warnings options.
This means autoheader prints warnings that a regular invocation
of autoconf would also print, so in the common case where both
are being run by autoreconf, the warnings are duplicated.
autoscan doesn’t pass down warnings options but it _does_ leave
the WARNINGS environment variable alone, which means it may issue
completely spurious warnings because the configure script is still
under construction.
Change this so that both programs disable all warnings for the
subsidiary invocation of autoconf, by not passing any warnings
options themselves, and by setting the WARNINGS environment variable
to “none” for the subprocess. For this to work correctly, the
‘args: --warnings syntax’ line has to be removed from autom4te.cfg
(m4sugar section). Since syntax warnings are on by default anyway,
the sole effect of this is to allow WARNINGS=none to turn off syntax
warnings.
The test suite changes are all to remove expectations of duplicate
diagnostics from autoheader.
* bin/autoheader.in: Do not pass warnings options down to subsidiary
autoconf, and set WARNINGS=none in the environment for that process.
* bin/autoscan.in: Set WARNINGS=none in the environment for subsidiary
autoconf.
* lib/autom4te.in (M4sugar): Remove ‘--warnings syntax’.
* tests/semantics.at, tests/torture.at: No longer expect various
diagnostics from autoheader as well as autoconf.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This function merges a list of warnings categories into the environment
variable WARNINGS, returning a new value to set it to. The intended use
is in code of the form
{
local $ENV{WARNINGS} = merge_WARNINGS ("this", "that");
# run a command here with WARNINGS=this,that,etc
}
This is not used yet, but will be in the next patch.
* lib/Autom4te/ChannelDefs.pm (merge_WARNINGS): New function.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ChannelDefs.pm *ought* to be kept in sync between automake and autoconf,
because it defines the set of valid -W options, and autoreconf assumes
that it can pass arbitrary -W options to all of the tools it invokes.
However, it isn’t covered by either project’s ‘make fetch’ and it hasn’t
actually *been* in sync for more than 17 years.
This patch manually brings over all of the changes made on the
automake side. Once the complementary patch is applied by the
automake team, both versions of the file will be the same, and then we
can add it to the list in fetch.pl and not have this problem any more
in the future.
There are some user-visible consequences to bringing this file back
into sync. The only one worth mentioning in NEWS is that the ‘obsolete’
category of warnings is now on by default. This had quite a bit of
fallout throughout the testsuite. There are also some new warning
categories that get mentioned in --help output, but we don’t actually
generate any warnings in those categories, so people using ‘-Wall’
won’t see any change. More diagnostics are automatically tagged with
‘warning:’ or ‘error:’, which also had some fallout in the testsuite.
Finally, ‘-Werror’ no longer causes complaints about unknown warning
categories to be treated as hard errors.
Internally, there are some small API changes: ‘parse_warnings’ is no
longer usable as a ‘getopt’ callback function, and we now have a stub
Autom4te/Config.pm to match the automake code’s expectations. (This
file *should* also be synced from automake by ‘make fetch’, but we
can’t quite do that yet because it’s a generated file and our build
system is not prepared to handle adding *two* directories to @INC when
running a not-yet-installed Perl script. I plan to fix that after 2.70.)
As a side-effect of adding a Config.pm, ‘prog_error’ now says to
report the bug to bug-autoconf, not bug-automake. If this is why we
mostly haven’t been using prog_error for internal errors, we can stop
avoiding it. (I did not change anything to use prog_error in this
patch.)
* lib/Autom4te/ChannelDefs.pm: Merge from automake.
* lib/Autom4te/Config.pm: New file.
* lib/local.mk (dist_perllib_DATA): Add Autom4te/Config.pm.
* bin/autoconf.as: Update list of warning categories to match
Autom4te::ChannelDefs::usage.
* bin/autoheader.in (@warnings): New global.
(parse_args): Don’t use parse_warnings as a getopt callback.
(main): Add warnings options from our command line to $autoconf.
No need to turn on 'obsolete' warnings explicitly.
No need to include "warning: " in warning messages.
* bin/autom4te.in (parse_args): Don’t use parse_warnings as a getopt callback.
(main): No need to include "warning: " in warning messages.
* bin/autoreconf.in (parse_args): parse_warnings now takes only one argument.
* bin/autoupdate.in: Set WARNINGS=none in environment for all child processes.
* tests/local.at
(AT_CHECK_M4): Handle `autom4te: error: /usr/bin/m4 ...` like
`autom4te: /usr/bin/m4 ...`.
(_AT_CHECK_AC_MACRO): Add AUTOCONF-FLAGS argument, passed to both
autoconf and autoheader.
(AT_CHECK_MACRO): Default AUTOCONF-FLAGS argument to empty.
Pass that argument to autoheader as well as autoconf.
(AT_CHECK_AU_MACRO): Expect a “macro ‘NAME’ is obsolete’ diagnostic
on the first run of autoconf. Pass -Wno-obsolete to autoconf on the
second run, and to autoheader on both runs.
* tests/base.at
* tests/c.at
* tests/compile.at
* tests/m4sh.at
* tests/m4sugar.at
* tests/semantics.at
* tests/tools.at
* tests/torture.at:
No need to pass -Wobsolete to autoconf.
Pass -Wno-obsolete to autoheader where needed to avoid handling
the same warning twice.
Update various expectations for diagnostics to match behavior
changes.
* tests/tools.at (autoupdating AU_ALIAS): Add an AC_CONFIG_HEADERS
line to the test configure.ac to eliminate an unrelated diagnostic.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At file scope of a file containing at most one ‘package’ declaration,
‘use vars’ is exactly equivalent to ‘our’, and the latter is preferred
starting with Perl 5.6.0, which happens to be the oldest version we
support.
In one place ‘our’ was not actually necessary and was switched to ‘my’.
(This change has already been made in Automake and applied to the
shared Perl code via the previous ‘make fetch’ commit.)
* lib/Autom4te/C4che.pm
* lib/Autom4te/ChannelDefs.pm
* lib/Autom4te/General.pm: Replace all uses of ‘use vars’ with ‘our’.
* bin/autoheader.in: Replace all uses of ‘use vars’ with ‘our’.
Remove an unnecessary ‘local’.
* bin/autoscan.in: Convert ‘use vars’ variables to ‘my’ variables.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All of the AC_PROG_*CPP macros fall back to ‘/lib/cpp’ if invoking the
relevant compiler with ‘-E’ doesn’t work. This is an obsolete
location to find the C preprocessor. Linux distributions tend to ship
a compatibility symlink, as do Solaris and AIX (as of the versions in the
GCC compile farm, anyway), but the BSDs no longer do.
The tests for this fallback are already expecting ‘cpp’ to be a
command findable via $PATH, so make the probe macros do the same
thing. (We still try ‘/lib/cpp’ if ‘cpp’ _isn’t_ in $PATH.)
* lib/autoconf/c.m4
(AC_PROG_CPP, AC_PROG_CXXCPP, AC_PROG_OBJCPP, AC_PROG_OBJCXXCPP):
If $CC / $CXX / $OBJC / $OBJCXX -E (respectively) does not run the
preprocessor, look for ‘cpp’ in $PATH before falling back to ‘/lib/cpp’.
* doc/autoconf.texi
(AC_PROG_CPP, AC_PROG_CXXCPP, AC_PROG_OBJCPP, AC_PROG_OBJCXXCPP):
Update to match.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Search-and-replace change ‘use warnings;’ to ‘use warnings FATAL => 'all';’
in all Perl code.
Notwithstanding the dire cautions in ‘perldoc warnings’ about this,
I think it’s the right call for us. One file was already doing it.
No new testsuite failures are observed on Linux with Perl 5.30.3
nor on NetBSD with Perl 5.6.1.
* bin/autoheader.in, bin/autom4te.in, bin/autoreconf.in
* bin/autoscan.in, bin/autoupdate.in, bin/ifnames.in
* lib/Autom4te/C4che.pm, lib/Autom4te/ChannelDefs.pm
* lib/Autom4te/Channels.pm, lib/Autom4te/Configure_ac.pm
* lib/Autom4te/FileUtils.pm, lib/Autom4te/General.pm
* lib/Autom4te/Request.pm, lib/Autom4te/XFile.pm:
Make all warnings from the Perl interpreter into fatal errors.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Autom4te::XFile does not appear to have any use for Carp, DynaLoader,
or File::Basename.
This happened to catch my eye while I was doing the previous two
patches. I have not done a comprehensive audit of imports in the Perl
code.
* lib/Autom4te/XFile.pm: Remove ‘use’s of Carp, DynaLoader,
and File::Basename.
(@ISA): Remove DynaLoader.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All the Perl scripts and modules now ‘use’ other modules in the
following order:
- use 5.006; use strict; use warnings; in that order.
If a file was not already use-ing one of these three, it was added.
- The BEGIN block that adds the installation directory for the
Autom4te:: modules to @INC, if necessary.
- All stdlib modules whose name begins with a capital letter,
in ASCII sort order.
- All Autom4te:: modules, in ASCII sort order.
- ‘use vars qw (...)’, if any, last.
Also, ‘use foo qw (...)’ and @ISA lists have been sorted into ASCII
sort order. (@EXPORT lists, which often follow immediately after @ISA
lists, have *not* been sorted, as these appear to have been organized
semantically in many cases.) qw delimiters have been normalized to
round parentheses with a space between the qw and the open paren.
* bin/autoheader.in, bin/autom4te.in, bin/autoreconf.in
* bin/autoscan.in, bin/autoupdate.in, bin/ifnames.in
* lib/Autom4te/C4che.pm, lib/Autom4te/ChannelDefs.pm
* lib/Autom4te/Channels.pm, lib/Autom4te/Configure_ac.pm
* lib/Autom4te/FileUtils.pm, lib/Autom4te/General.pm
* lib/Autom4te/Getopt.pm, lib/Autom4te/Request.pm
* lib/Autom4te/XFile.pm: Rationalize order and format of ‘use’
directives and @ISA lists. Add any of ‘use 5.006’, ‘use strict’,
and ‘use warnings’ that was not already present.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some downstream redistributors for Autoconf wish to use
‘/usr/bin/env perl’ as the #! line for the installed Perl scripts.
This does not work with command-line options on the #! line, as the
kernel doesn’t support supplying more than one argument to a #!
interpreter (this limitation is universal across Unixes that
support #!, as far as I know).
Remove ‘-w’ from all perl #! lines and instead add ‘use warnings’
to all the scripts and .pm files that didn’t already have it.
This ‘use’ directive was added to Perl in version 5.6.0 (aka 5.006)
so there is no change to our minimum Perl requirement.
(It is necessary to add ‘use warnings’ to all the .pm files as well as
the scripts, because the ‘-w’ command-line option turns on warnings
globally, but ‘use warnings’ does so only for the current lexical scope.)
Patch uplifted from OpenEmbedded, originally by Serhii Popovych.
It’s a mechanical search-and-replace change so I do not believe a
copyright assignment is necessary.
* bin/autom4te.in, bin/autoreconf.in, bin/autoscan.in
* bin/autoupdate.in, bin/ifnames.in: Remove -w from #! line
and add ‘use warnings’ to imports.
* lib/Autom4te/C4che.pm, lib/Autom4te/ChannelDefs.pm
* lib/Autom4te/Channels.pm, lib/Autom4te/Configure_ac.pm
* lib/Autom4te/FileUtils.pm, lib/Autom4te/General.pm
* lib/Autom4te/Request.pm, lib/Autom4te/XFile.pm:
Add ‘use warnings’ to imports.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
‘make maintainer-check-c++’ has two test failures that don’t show in
an ordinary ‘make check’. One of these is a pair of problems with the
semantics.at test of AC_CHECK_DECL(S):
* AC_CHECK_DECL cannot handle a function argument whose declared type
is ‘char []’; it generates a cast to the array type, which is
invalid in both C and C++. This was masked by an M4 quotation bug,
causing it to emit a cast to ‘char’ instead, prodicing code that
was valid C but invalid C++. I don’t think it’s practical to teach
AC_CHECK_DECL to do argument type decay, so I changed the type
signature in the AC_CHECK_DECL call (not in the actual declaration)
to ‘char *’. Conveniently this also avoids the quotation issue.
* In C++, apparently ‘extern struct { int x; } foo;’ is invalid.
(clang++ explains at length: “variable ‘foo’ is used but not
defined in this translation unit, and cannot be defined in any
other translation unit because its type does not have linkage.”)
Fixed by giving the struct a tag.
The other failure is an actual bug in AC_PROG_LEX: the test program
used by _AC_PROG_LEX_YYTEXT_DECL uses the flex utility function
‘input’, which is renamed to ‘yyinput’ when the scanner is compiled as
C++. Fixed with ifdefs in the offending action--it might seem cleaner
to use a macro defined in a %{ %} block, but that would be inserted into
the skeleton *above* the declaration of (yy)input, so I didn’t feel
it was safe.
* tests/semantics.at (AC_CHECK_DECLS): Adjust test programs for C++
compatibility and to work around lack of support for argument type
decay.
* programs.m4 (_AC_PROG_LEX_YYTEXT_DECL): Call yyinput(), not input(),
in scanner action when scanner is compiled as C++.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recently ‘make syntax-check’ added a lint rule discouraging use of
bare ‘strcmp’ (in favor of gnulib’s streq/strneq wrappers), which
triggers on some code in c.m4’s test for C++98 compliance.
This lint rule makes sense for typical C programs coded to GNU’s
standards, but not for autoconf’s test programs. There is no way to
disable it from outside the code, so this patch adds parentheses
around the name ‘strcmp’, which is sufficient to disable this
grep-based lint but doesn’t change the meaning of the code as
understood by an actual C++ compiler.
* c.m4 (_AC_CXX_CXX98_TEST_HEADER): Suppress ‘make syntax-check’
error on use of strcmp.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A patch was recently proposed for GNU libc to make *all* processes
start up with file descriptors 0, 1, and 2 guaranteed to be open.
Part of the rationale for this patch was that configure scripts fail
catastrophically if these fds are closed, even if you just want to run
--help or --version, e.g.
$ ./configure --version <&-; echo $?
./configure: line 555: 0: Bad file descriptor
1
configure scripts cannot rely on behavior specific to GNU libc, so
whether or not that patch gets committed, it makes sense for us to
make configure scripts robust against being started up with closed
stdin/stdout/stderr.
This patch adds code to ensure fds 0, 1, and 2 are open, early in
_AS_SHELL_SANITIZE. It uses a construct, ‘(exec 3>&n)’, that’s known
not to work in very old shells, but that’s OK because those shells
will be rejected by _AS_DETECT_BETTER_SHELL anyway. The worst-case
scenario is that the “This script requires a shell more modern than
all the shells I found on your system” error message won’t get printed.
When these fds are found not to be open, we open them on /dev/null, in
the normal I/O direction (0 for reading, 1 and 2 for writing). There
is a case for opening them in the *opposite* direction so that, for
instance, writes to fd 1 will fail when fd 1 started out closed.
However, that would expose latent bugs that I think should be dealt
with *after* 2.70. (See Savannah bug #110300 for more detail.)
I also took the opportunity to rationalize the order of operations in
_AS_SHELL_SANITIZE a little. All the special shell and environment
variables that we care about are dealt with immediately after
AS_BOURNE_COMPATIBLE, and _AS_PATH_SEPARATOR_PREPARE happens
immediately before the first use of _AS_PATH_WALK.
* lib/m4sugar/m4sh.m4 (_AS_ENSURE_STANDARD_FDS): New macro.
(_AS_SHELL_SANITIZE): Move the “Unset variables that we do not need”
and “NLS nuisances” blocks immediately after setting IFS; merge the
unsetting of CDPATH into the main unsetting loop; move invocation of
_AS_PATH_SEPARATOR_PREPARE to immediately above the “Find who we are”
block; invoke _AS_ENSURE_STANDARD_FDS immediately before
_AS_PATH_SEPARATOR_PREPARE.
* tests/base.at (configure with closed standard fds): New test.
* tests/torture.at (--help and --version in unwritable directory): New test.
|
| |
|
|
|
|
|
|
|
| |
Reported at <https://savannah.gnu.org/support/index.php?110296>.
* lib/autoconf/types.m4 (AC_TYPE_PID_T): Define pid_t to '__int64' on 64-bit
native Windows, and to 'int' otherwise.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fallout from the previous change, which I should’ve tested on a
machine without Erlang tools installed, before pushing.
It bugs me a little that we have to put these special exit codes into
autoconf itself instead of the testsuite, but it is what it is.
* lib/autoconf/erlang.m4 (AC_ERLANG_NEED_ERLC, AC_ERLANG_NEED_ERL):
Exit with code 77 on failure so testsuite understands to skip Erlang
tests in this case.
(AC_ERLANG_CHECK_LIB): Use AC_ERLANG_NEED_ERLC and AC_ERLANG_NEED_ERL
instead of the _PATH_ versions.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This causes our testsuite to report a skipped test, rather than a
failure, if the detected compiler for _AC_LANG produces broken
executables. It matches the behavior of _AC_COMPILER_EXEEXT_DEFAULT,
which has exited with that code for a long time if it hits the
“_AC_LANG compiler cannot *create* executables” failure case.
Partially addresses bug #110267. The Solaris 10 machine I have access
to, has a broken gccgo installation that generates executables that
crash on startup. Without this patch, test “358: Go” fails. With
this patch, it is skipped.
|
|
|
|
|
|
|
| |
In addition to the gtkdocize tool, gtk-related software may utilize the
IT_PROG_INTLTOOL macro in order to require the intltoolize tool. So too
here should the tool be run by autoreconf itself, in order to guarantee
its initialization via the unified frontend for all autotools projects.
|
|
|
|
|
|
|
|
|
|
| |
When the GTK_DOC_CHECK macro is in use, this flags a given configure.ac
as belonging the the common class of gtk-related software that requires
the gtkdocize tool to be run before autoreconf, in order to install the
gtk-doc macro and Makefile fragment. Make this easier to accomplish via
teaching autoreconf how to detect and run this tool automatically; this
gets us one step closer to a world in which `autoreconf -fi` on its own
is enough to bootstrap any autotools project into a configurable state.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is almost always incorrect for a configure script to omit either
AC_INIT or AC_OUTPUT. Issue warnings in the ‘syntax’ category for
this.
The implementation is, unfortunately, a bit of a kludge. To check for
the _absence_ of a macro invocation, we can use m4_provide_if inside a
m4_wrap hook. However, if we activate the m4_wrap hook directly from
general.m4, we get spurious warnings at freeze time. We also get
warnings whenever a script that’s missing AC_INIT and/or AC_OUTPUT
is *traced*, which means we get double warnings from autoconf, and
autoheader and aclocal complain about it too, which seems unnecessary.
A clean way to deal with this would be to make the hook look for a
special macro that’s defined only when autoconf (the program) is
invoked without any --trace arguments. Unfortunately, autom4te
doesn’t pass --define down to M4, and changing that would involve
coordinating with Automake (the project), so instead I’ve gone for the
kludge: a new file lib/autoconf/trailer.m4 that calls m4_wrap. This
file is *not* included in autoconf.m4f, but it’s installed, and it’s
added to the m4 invocation by autoconf (the program) only when not
tracing. (It still uses m4_wrap, because we pass it to m4 *before*
configure.ac, because otherwise we get nonsense locations for any
*other* diagnostics coming out of this autoconf invocation. I don’t
know why.)
The additional checks in autoreconf are intended to make sure that if
autoreconf skips a directory entirely, you get told why.
Lots of tests in the testsuite didn’t bother with AC_OUTPUT, and
somewhat fewer didn’t bother with AC_INIT; where possible I just added
them.
Suggested by David A. Wheeler, who submitted a patch, but I didn’t
wind up using any of his code. (His implementation used an extra
tracing pass, only checked for a missing AC_INIT, and invented a new
command-line option to turn off this specific warning. I thought this
was tidier overall, despite the kludge.)
* lib/autoconf/general.m4 (_AC_FINALIZE): New macro: code to be run
when generating configure, after the entire configure.ac is
processed. Currently only checks that AC_INIT and AC_OUTPUT were
called at some point, issuing syntax-category warnings if not.
(AC_INIT, AC_OUTPUT): m4_provide self.
* lib/autoconf/trailer.m4: New file that just calls m4_wrap([_AC_FINALIZE]).
* lib/local.mk: Install new file.
* bin/autoconf.as: Add trailer.m4 to the final invocation of autom4te,
but only when not tracing.
* bin/autoreconf.in (autoreconf_current_directory): Distinguish in
diagnostics between “directory skipped because it doesn’t have a
configure.ac or configure.in” (e.g. Cygnus configure) and “directory
has a configure.ac but it doesn’t appear to be autoconf input.”
* tests/*.at: Fix all tests affected by the new warnings.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically, all five arguments, if present, are passed through
m4_normalize before doing anything else with them. For instance,
AC_INIT([ GNU Hello ], [1.0]) is now equivalent to
AC_INIT([GNU Hello], [1.0]).
As a consequence, newlines in the arguments to AC_INIT are now
converted to spaces and no longer trigger warnings.
Also, diagnose inappropriate contents of the fourth and fifth
arguments as well as the first three. The fifth argument should be
“usable as-is in single- and double-quoted strings and quoted and
unquoted here-docs,” like the first three. (This is the check
performed by _AC_INIT_LITERAL.) The fourth argument (TARNAME) is used
to construct filenames, so apply an even more stringent test, namely
AS_LITERAL_WORD_IF.
Suggested by David A. Wheeler, who submitted a patch, but I didn’t
wind up using any of his code.
* lib/autoconf/general.m4 (_AC_INIT_LITERAL): Not necessary to check
for newlines anymore.
(_AC_INIT_PACKAGE): Pass all five arguments through m4_normalize
before doing anything else with them. New warning: apply
_AC_INIT_LITERAL to fifth argument (URL). New warning: complain
if fourth argument (TARNAME) is not a literal word according to
AS_LITERAL_WORD_IF. Simplify a conditional by using m4_default.
* tests/base.at (AC_INIT with unusual version strings): Adjust to
match above changes, add more subtests.
|
|
|
|
|
|
|
|
|
|
| |
Although this cannot easily be done in general, there are a couple
of places where it’s easy.
* lib/autoconf/c.m4 (AC_LANG_INT_SAVE (C)):
Change ‘()’ to ‘(void)’ to pacify picky compilers.
Problem reported by Vincent Lefevre in:
https://lists.gnu.org/r/autoconf-patches/2020-08/msg00000.html
(AC_C_INLINE): Likewise.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test programs used by _AC_PROG_CXX_CXX98 and _AC_PROG_CXX_CXX11
can take several seconds to compile, even on current-generation CPUs.
Each of them may be test-compiled up to six times as the configure
script searches for appropriate command-line switches. This is
reported to cancel out all of the other performance gains made since
2.69.
Replace these programs with simpler ones that do not exercise the C++
standard *library* and can be compiled in less than a second each.
On my computer, which is quite new, the minimal configure script
AC_INIT
AC_PROG_CXX
executes in 4.5 seconds (wall-clock) before this change and 0.5
seconds after.
* lib/autoconf/c.m4 (_AC_CXX_CXX98_TEST_HEADER, _AC_CXX_CXX98_TEST_BODY):
Rewrite to test only C++ 1998 language features, not library features.
(_AC_CXX_CXX11_TEST_HEADER, _AC_CXX_CXX11_TEST_BODY):
Similarly for C++ 2011.
* doc/autoconf.texi (AC_PROG_CXX): Document this change.
|
|
|
|
|
|
|
|
|
| |
* lib/autoconf/status.m4 (_AC_OUTPUT_HEADER):
Use ‘>&1’, which is a no-op, to work around a bug in ksh93
Version JM 93t+ 2010-03-05 as used in OpenIndiana.
The bug causes ‘printf "foo"’ to mistakenly succeed in
some cases even though the underlying ‘write’ syscall fails.
The ‘>&1’ causes the printf to fail, as it should.
|
| |
|
|
|
|
|
|
|
|
|
| |
Gnulib removed this recently, and we should be consistent.
* doc/autoconf.texi (Autoheader Macros):
Use a more up-to-date example.
* lib/autoconf/functions.m4 (CRAY_STACKSEG_END): Remove.
This is backported from the following Gnulib patch:
https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=41a2d446c7984f8f39e3eeca40c6d30630969c10
|
|
|
|
|
|
|
| |
Problem reported by Bill Dieter in:
https://lists.gnu.org/r/bug-autoconf/2020-07/msg00089.html
* lib/autoconf/fortran.m4 (_AC_FC_LIBRARY_LDFLAGS):
Defend against ‘clang -mllvm -loopopt=0’.
|
|
|
|
|
|
|
|
| |
Problem reported by Bruno Haible in:
https://savannah.gnu.org/support/?110273#comment6
* lib/autoconf/general.m4 (_AC_ARG_VAR_VALIDATE):
* tests/autotest.at (C unit tests, C unit tests (EXEEXT)):
Prefer ‘${MAKE-make}’ to ‘make’ in shell code.
|
|
|
|
|
|
|
|
|
|
|
| |
* lib/freeze.mk (MY_AUTOM4TE, build_libdir, m4f_dependencies):
Prefer ‘$(top_build_prefix)’ to ‘$(top_builddir)/’.
The difference matters on AIX 7.1, where ‘make’ doesn’t know that
bin/autom4te and ./bin/autom4te are the same file,
and gets confused about dependencies without this change.
‘$(top_build_prefix)bin/autom4te’ expands to ‘bin/automake’
whereas ‘$(top_builddir)/bin/autom4te’ expands to
‘./bin/automake’, and the former works where the latter doesn’t.
|
|
|
|
|
|
|
|
| |
* NEWS, doc/autoconf.texi, lib/autoconf/fortran.m4:
Document 250, not 254.
* tests/fortran.at (AC_FC_LINE_LENGTH): Test lines with 250
columns not 253, since Oracle Studio 12.6 Fortran 95 8.8
2017/05/30 goes up only to 250.
|
|
|
|
|
|
|
| |
* lib/autoconf/functions.m4 (AC_FUNC_SELECT_ARGTYPES):
* lib/autoconf/programs.m4 (AC_FUNC_SELECT_ARGTYPES):
* lib/autotest/general.m4 (AT_INIT):
Rewrite to avoid ${VAR-VALUE} where VALUE is not a shell word.
|
|
|
|
|
|
|
|
|
|
| |
- Better explanation of the additional tests performed by this macro,
once the tool has been located.
- Update advice re using Flex to generate a bundled lex.yy.c.
- Remove text describing a bug in Automake that has long since been
corrected.
|
|
|
|
|
|
|
| |
Suggested by Zack Weinberg in:
https://lists.gnu.org/r/autoconf-patches/2020-07/msg00016.html
* lib/autoconf/programs.m4 (_AC_PROG_LEX_YYTEXT_DECL):
Define yywrap too.
|
|
|
|
|
|
|
|
| |
Problem reported by Ross Burton in:
https://savannah.gnu.org/support/?110269
* lib/autoconf/programs.m4 (_AC_PROG_LEX_YYTEXT_DECL):
If tests indicate that LEX or LEXLIB does not work, set LEX to ":"
and LEXLIB empty, instead of failing out of 'configure' entirely.
|