Before we got an error when libqrencode was not installed:
`src/ui/console.c:52:10: fatal error: qrencode.h: No such file or
directory`
Which looked like HAVE_QRENCODE was true.
config.status showed:
`config.status:D["HAVE_QRENCODE"]=" 0"`
Holger pointed to me that there is not just true and false but defined
and undefined.
So one solution was to use `#if HAVE_QRENCODE == 1` to check for the
actual value.
Or dont define HAVE_QRENCODE in the non present case at all.
In all the other HAVE_ variables we use this approach.
I think i at first chose the wrong way out of confusion with BUILD_ and
HAVE_.
Option -ggdb3 (same as -g3) doesn't affect code-generation, just adds
to the binary size of an executable. Automake strips installed
binaries automatically when "make install-strip" is run so enabling
this option permanently doesn't affect the end result while allowing
for hassle-free interactive debugging.
If one is running a stripped binary it's still possible to attach GDB
by process PID and then use "file /path/to/unstripped/profanity" to
get all symbols and lines data.
Autoconf can pre-populate this variable with essential parameters so
it should be appended to rather than overridden.
While at it, don't miss to append CFLAGS for libstrope which is needed
if it's installed to a non-default location.
AM_INIT_AUTOMAKE requires AC_ARG_PROGRAM so should go after
AC_CANONICAL_TARGET for proper program name mangling.
This fixes "AC_ARG_PROGRAM was called before AC_CANONICAL_TARGET"
warning as emitted by autoconf 2.69.
Fixing build failure detected by sr.ht for OpenBSD:
```
src/ui/inputwin.c: In function '_inp_rl_startup_hook':
src/ui/inputwin.c:444:5: error: implicit declaration of function 'rl_bind_keyseq'; did you mean 'rl_bind_key'? [-Werror=implicit-function-declaration]
444 | rl_bind_keyseq("\\e1", _inp_rl_win_1_handler);
| ^~~~~~~~~~~~~~
| rl_bind_key
cc1: all warnings being treated as errors
```
Seems like both OSX and OpenBSD need CPPFLAGS here.
Previously it relied on AX_PYTHON_DEVEL, which in turn executes
python-config to get the build flags. However this does not work while
cross compiling because we can't execute the python-config build for the
target platform. To circumvent this problem the python build flags are
now queried via pkgconfig, which has the drawback of not having some
extra build flags, but they do not seem to be needed.
I tested this patch with the termux build system and it build without
their existing hack of injecting python after the configure step. I also
tested non cross compile build on Arch Linux and it also still works.
Fixes#851
Remove support for libsignal-protocol-c < 2.3.2.
Debian 10 uses 2.3.2, Debian 11 and 12 use 2.3.3.
openSUSE from 15.2 onward uses 2.3.3.
Fedora since 28 uses 2.3.2.
We should be good.
Instead of checking for `lib` directories, let's make sure `libreadline`
exists.
Also, let's improve the error message if we can't find it. Finally,
since we're only looking for `brew` on macOS, we don't need to use
`$PATH_SEPARATOR` since we know what the path separator is.
Currently, `configure.ac` assumes Readline is installed via Homebrew in
`/usr/local`. This doesn't work for Homebrew on Apple Silicon, or
MacPorts.
Let's fix this by checking for a `brew` installation, and querying that
for Readline's prefix if available. If not, it checks for an existing
MacPorts prefix, and finally falls back to checking `/usr/local` in case
a user installed Readline for themselves there.
Two options to install plugins.
Mention the whole path:
`/plugins install ~/src/profanity-plugins/my.py`
Mention only the plugin name:
`/plugins install my.py`
The latter will look in `/usr/local/share/profanity/plugins/` for the
file and copy it over to `~/.local/share/profanity/plugins`.
At first I was thinking about loading the plugins from the global
location. But users most likely don't want to have all plugins activated
that an admin installs on a system.
Regards https://github.com/profanity-im/profanity/issues/945
