Gettext-0.20 is the first version where its `autopoint` does not
overwrite the newer 'extern-inline.m4' from gnulib.
Version 0.20 is five years old, so most users will be on a distro
that includes that version of gettext or a newer one.
This makes more sense than letting the formatter and the linter depend
on ENABLE_COLOR (which maybe should have been named ENABLE_SYNTAX).
This fulfills https://savannah.gnu.org/bugs/?50080.
By passing --disable-maintainer-mode to ./configure the user can disable
autoconf build rules that would cause configure to be rebuilt and rerun.
Kind-of-requested-by: Mike Frysinger <vapier@gentoo.org>
Fix building with x86_64-w64-mingw32 to cross-compile native Windows
programs. Need to:
* add checks for missing functions
* don't use signals that are unavailable on the platform
* avoid useless non-Linux sys/ioctl.h include
* use putenv instead of setenv as the latter is unavailable
Since commits b0209374 and 1c010d8e from a month ago, nano does not use
mblen() and mbtowc() any more, so there is no need to check for their
presence.
Instead, add a check for iswalpha(), which we do use.
This probing has been changed four times in the past:
git log --grep get_wch
In March 2005, commit 2161fa62 changed the probe from get_wch() to
wget_wch(), reasoning that "get_wch() might be a macro instead of
a function". (Four months earlier, commit 3ba9c351 changed it
from addwstr() to wget_wch(), probably for the same reason.) But
three months later, in commit 25799f68, the probe gets changed to
get_wch() again, because "it's a more generic function"...
It seems clear that the non-macro argument is the stronger one.
See the NOTES section in 'man get_wch' for its possible macroness.
This addresses https://savannah.gnu.org/bugs/?58997.
Reported-by: Randall S. Becker <rsbecker@nexbridge.com>
The Haiku recipe seems to detect a .git directory somewhere, even though
they are building from a tarball. So, check instead for the presence of
nano's release script, which ought to be present only in a git checkout,
not in a released tarball.
We do not provide an RPM package. And distros like Fedora, Mageia,
and Suse have their own spec files -- they don't need ours. And in
case anyone would like to create their own RPM package from nano,
they can look at the spec files of those distros.
Benno Schulenberg