The switch to the meson build system broke plugins on macOS. GNU libtool
builds shared libraries with ".dylib" and shared modules (plugins) with
the extension ".so", but meson is using ".dylib" for both.
Although overriding the name_suffix for shared_module() in meson is
possible, this would be messy for other platforms as there is no way to
query the default. Therefore it seems like we have to go with ".dylib"
for now on macOS.
However, G_MODULE_SUFFIX is defined to ".so", because glib follows what
GNU libtool does. Therefore define a separate preprocessor macro that
has the correct extension.
See: https://github.com/mesonbuild/meson/issues/1160
With the switch to meson, the problem previously fixed in #1822 came
back. The build system might pick up the installed hexchat-config.h
instead of using the header in the source directory, as the compiler
arguments would be in the order of "-I${prefix}/include -I..".
It seems that the c_args in meson are always put to the front of the
compiler arguments, in order to be able to override any include paths
from dependencies. However, this was not the intention here, so perl
should also be modeled as a dependency. This ensures that the arguments
with local include directories come first.
When hexchat is already installed into a non-default prefix, a new build
could pick up ${prefix}/include/hexchat-plugin.h from the installed
version instead of the local header, as configuration variables such as
$(GLIB_CFLAGS) would point to -I${prefix}/include.
Reordering the includes and moving -I arguments to CPPFLAGS prevents
this, as it ensures the local directories are always searched first.
This was no problem when compiling for /usr or /usr/local as these
directories in the compiler search path are always searched last.
Closes#1822
Rainer Müller