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
This partly reverts d3a387a0ec.
For proanity 0.9.x we still wanted to support older glib versions so
that we can be packaged for various linux distros.
Now with 0.10 we want to move on.
- Add NetBSD as a recognized platform without -ldl.
- Allow building with NetBSD libcurses instead of ncurses.
- Portability to NetBSD sh - use POSIX '=' instead of '=='.
With recent changes to c99 and -D_POSIX_C_SOURCE=200809L we get the following:
openSUSE TW CI sais:
```
Now you can run `make' to build profanity
In file included from /usr/include/python2.7/Python.h:8,
from src/plugins/python_plugins.c:37:
/usr/include/python2.7/pyconfig.h:1226: error: "_POSIX_C_SOURCE" redefined [-Werror]
1226 | #define _POSIX_C_SOURCE 200112L
|
<command-line>: note: this is the location of the previous definition
In file included from /usr/include/python2.7/Python.h:8,
from src/plugins/python_api.c:37:
/usr/include/python2.7/pyconfig.h:1226: error: "_POSIX_C_SOURCE" redefined [-Werror]
1226 | #define _POSIX_C_SOURCE 200112L
|
<command-line>: note: this is the location of the previous definition
cc1: all warnings being treated as errors
```
OpenBSD CI sais:
```
cc1: warnings being treated as errors
src/database.c: In function 'log_database_get_previous_chat':
src/database.c:226: warning: implicit declaration of function 'asprintf'
gmake[1]: *** [Makefile:1924: src/database.o] Error 1
gmake[1]: Leaving directory '/home/build/profanity'
gmake: *** [Makefile:1211: all] Error 2
```
Let us use gnu99. Has been proposed before already and is fine.
Regards https://github.com/profanity-im/profanity/issues/1357
Regards https://github.com/profanity-im/profanity/pull/1351
98c38dc6d6
sets C99 as standard.
strdup() is not part of C99.
For now set `-D_POSIX_C_SOURCE=200809L` macro to have strdup() in C99.
Using `gnu99` instead would be another option.
We should take more care to use glib functions whenever possible.
Regards https://github.com/profanity-im/profanity/issues/1357
Some systems don't provide recent libstrophe releases. When older
version of libstrophe is detected, don't build legacy auth support.
To simplify this patch, report about unsupported legacy auth and
keep commands option as is.
without this, i receive this error on openbsd 6.7:
src/event/server_events.c:1477:19: error: universal character names are only valid in C++ and C99
src/event/server_events.c:1478:19: error: universal character names are only valid in C++ and C99
gmake[1]: *** [Makefile:1925: src/event/server_events.o] Error 1
gmake[1]: Leaving directory '/home/toogley/profanity'
gmake: *** [Makefile:1212: all] Error 2
After the library is found by pkg-config, try to build a simple program
to check the installation. The motivation of this check is that the
chance that users manually install libstrophe/libmesode is higher than
for other libs.
Fixes#1334.
Use g_date_time_format() instead of g_date_time_format_iso8601() to only
rely on glib 2.56.0 which is the latest version in Debian Buster
(current stable).
We also only use basic sqlite functions so 3.27.0 should be fine there
(also the one in Debian buster).
Thanks to @DebXWoody.
