Building plugins

Hi,

This thread will be about building plugins, problems experienced and questions.

  1. You must install clang.
    On a Debian/Ubuntu system, that’s sudo apt install clang.

  2. Missing fmt
    Like expalined in Plugin development 101 - #6 by agsantos, you must enable it first. The correct syntax is:

cd daemon/contrib && mkdir native && ../bootstrap --enable-fmt && make .fmt

EDIT: add missing . like explained in following message.
EDIT2: add missing contrib directory.

  1. Don’t do make clean: it deletes all rules.mak files in the contrib directory! And then you can’t run make again…
Makefile:412: .../jami-plugins/daemon/contrib/src/*/rules.mak: No such file or directory
make: *** No rule to make target '.../jami-plugins/daemon/contrib/src/*/rules.mak'.  Stop.

If it occurs to you, do git restore . to restore all files that were deleted by the make clean.

  1. Now, even with fmt enabled, build.sh script still fails:
$ ./build.sh 
DAEMON not provided, building with ./../../daemon
PLATFORM not provided, building with linux-gnu
Other options: redhat-linux
In file included from TranslateChatSubscriber.cpp:21:
In file included from ./TranslateChatSubscriber.h:23:
In file included from ./../../daemon/src/observer.h:35:
./../../daemon/src/logger.h:27:10: fatal error: 'fmt/core.h' file not found
#include <fmt/core.h>
         ^~~~~~~~~~~~
1 error generated.
... etc.

Do we need to define a specific CPATH value to reach this include file or is it a bug in the Makefile?

Good mornign @pmetras,

When dependency erros happen while building either jami or any plugin, two main things might be the cause: either the dependency path is not added to your build script or the dependency was incorrectly built.

The first case can be checked in the build.sh script (if you are under GNU/Linux, MacOS or Android) or in the CMakeLists.txt if in Windows.

From the AutoAnswer build script for GNU/Linux:

# Compile
    clang++ -std=c++17 -fPIC ${CLANG_OPTS} \
    -Wl,-rpath,"\${ORIGIN}" \
    -Wall -Wextra \
    -Wno-unused-parameter \
    ${EXTRA_DEFINES} \
    -I"." \
    -I"${DAEMON_SRC}" \
    -I"${CONTRIB_PATH}/${CONTRIB_PLATFORM}/include" \ <- HERE YOU SHOULD FIND A FMT DIRECTORY
    -I"${PLUGINS_LIB}" \
    ./../lib/common.cpp \
    PluginPreferenceHandler.cpp \
    BotChatHandler.cpp \
    BotPeerChatSubscriber.cpp \
    main.cpp \
    -L"${CONTRIB_PATH}/${CONTRIB_PLATFORM}/lib/" \ <- HERE YOU SHOULD FIND libfmt.a
    ${EXTRA_DEBUG_LIBRARIES} \
    -o "${OUTPUT}"

Note: in my system ${CONTRIB_PATH}/${CONTRIB_PLATFORM} is <daemon>/contrib/x86_64-linux-gnu

For the latter, what i usually do is cleaning both the daemon and the plugin repositories and then rebuild:

$ git clean -xdf (on both daemon and plugin repositories)
$ cd <daemon/contrib> && mkdir native && cd native && ../bootstrap --enable-fmt && make -j

make -j will build a bunch of things so if you only want to build fmt, make -j .fmt is better.

Then i proceed with the plugin build.

Note:

make .fmt is the correct command.
make fmt will only download the source and will not build the library.

Thank you! At least now I can compile a plugin (or I least I don’t get compilation errors)… The important points:

  1. Enabling the fmt dependency with bootstrap --enable-fmt
  2. Creating the missing directory daemon/contrib/native.
  3. Effectively building the dependency with make .fmt

Can these steps be added to the Makefile or build.sh so that the first step to building a plugin is easier?

Then the plugin can be compiled with:

python3 build-plugin.py --projects=<PluginName>

In order to have build-plugin.py working on Debian, I had to patch the Python script and define DEBIAN_DISTRIBUTION_NAME = "debian" and add this variable in the supported_distros list. I can submit a merge request if desired but it’s really a simple change.

Finaly, the resulting <PluginName>.jpl file is available in build/x86_64-linux-gnu/ directory (in the case of a Linux platform).

Good to know you can continue with your plugin development!

A for the Debian build, we would be pleased to receive a patch.
For contributions, please use our gerrit repository, we do not accept merge requests in the gitlab.