At least in OpenBSD, there is a libedit library in base, but without
public headers. Public headers for readline are available but since
15db5d36 (pcre2test: avoid using readline headers with libedit,
2022-04-07) won't be picked up automatically.
Allow pointing cmake to those headers by doing (for example):
$ cmake -DEDITLINE_INCLUDE_DIR=/usr/include/readline
Or using custom CPPFLAGS with configure (for example):
$ CPPFLAGS=-I/usr/include/readline ./configure --enable-pcre2test-libedit
Since the headers from readline.h would be otherwise incomplete, detect
that case and pull the extra headers that are required automagically and
while at it, cleanup the NCURSES dependency that was unnecessarily copied
from readline.
* pcre2test: use the right header for libedit in FreeBSD with autoconf
When `./configure --enable-pcre2test-libedit` is used in FreeBSD,
the resulting test will succeed but won't set the necessary flag
to distinguish between libedit and readline header files, therefore
using readline's at built time (if installed)
Consolidate all header tests into one and use instead the corresponding
autogenerated defines to check for each possibility.
* pcre2test: really allow libedit with cmake
Using cmake to configure and enable linking pcre2test with libedit,
could result in a broken build, because the header used was instead
pointing to readline.
In cases were the build will succeed (because both libraries were
available), it would likely show warnings, because several history
functions were being used without declarations, since readline
requires including "history.h" for those.
Additionally, since PCRE2_SUPPORT_READLINE is ON by default (unlike
configure), turning PCRE2_SUPPORT_LIBEDIT=ON, would require setting
that other option to OFF explicitly (even if readline wasn't available)
or the setup would abort.
Lastly, in systems with no default sysroot (ex: macOS), the use of
absolute paths for searching for libedit's readline.h could fail so
use instead relative PATH_SUFFIXES.
* pcre2test: avoid using readline headers with libedit
When asked to enable libedit in a system that ALSO has readline,
the headers of the former would be found and used by the earlier.
While that would mostly work, some functions will be missing
definitions (which is forbidden in C99), so instead abort the
configuration and let the user provide for them.
It doesn't seem needed, and is apparently resulting in at least one
duplicated entry in the installation list that causes problems for
uninstalling.
Fixes: #46
Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
Since d5a61ee8 (Patch to detect (and ignore) symlink loops in
pcre2grep., 2021-08-28), there is optional code that depends
on readlink and PATH_MAX but that had only detection added for
the first.
GNU Hurd doesn't have the later so it fails to build.
Improve the detection to include both dependencies in autotools
and cmake to fix that.
Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
* cleanup: remove references to no longer used stdint.h
Since 19c50b9d (Unconditionally use inttypes.h instead of trying for
stdint.h (simplification) and remove the now unnecessary inclusion in
pcre2_internal.h., 2018-11-14), stdint.h is no longer used.
Remove checks for it in autotools and CMake and document better the
expected build failures for systems that might have stdint.h (C99)
and not inttypes.h (from POSIX), like old Windows.
* cleanup: remove detection for inttypes.h which is a hard dependency
CMake checks for standard headers are not meant to be used for hard
dependencies, so will prevent a possible fallback to work.
Alternatively, the header could be checked to make the configuration
fail instead of breaking the build, but that was punted, as it was
missing anyway from autotools.
William A Rowe Jr
GregThain
Carlo Marcelo Arenas Belón
Philip Hazel
Zoltán Herczeg