Toru Maesaka

Something notable that has changed in Drizzle this week is the build system for plugins.

Previously we were using the old plugin system that was inherited from MySQL but Drizzle now uses a Python based system that allows us to aggregate your plugin build rules to the top level Makefile. This change also gets rid of the nasty behavior that was giving people like Monty Taylor and other build system hackers heachaches.

But hey, as a plugin developer you’re not so interested in how things are handled cleanly inside right? you’re more interested in how to create or port your plugin over to the new build system! As a developer, you are interested in the following three files:

• plugin.ini
• plugin.ac
• plugin.am

where the mandatory file is plugin.ini. This file is where you write the basic details of the plugin like the name, source files and relevant compiler options. For example this is what plugin.ini looks like for the Blackhole storage engine:

[plugin]
name=blackhole
title=Blackhole Storage Engine
description=Basic Write-only Read-never tables
sources=ha_blackhole.cc
headers=ha_blackhole.h

You can also specify the plugin to be loaded by default with this line: “load_by_default=yes”. If you don’t add this line, the plugin is enabled by specifying it with the “–plugin_load” server startup option.

As for the optional plugin.ac and plugin.am files, these are where you can add your own autoconf and automake rules for the plugin. For example you might want to check/search for a library or build an internal library for your plugin.

Example of Linking an external library

If you write a plugin, you’ll most likely want to link a particular library to your program. After all, thats one of the major points of writing a plugin right? to bring the external goodness over to the database server for solving a particular need/requirement in your application.

For those that are interested, I’ll leave a snippet of how I linked Tokyo Cabinet to the storage engine I am currently working on. Firstly, you want to search whether Tokyo Cabinet exists in the environment that you’re building in. Clearly this is what configure is for so I added this to my plugin.ac:

AC_LIB_HAVE_LINKFLAGS(tokyocabinet,,
  [#include <tchdb.h>],
  [
     TCHDB hdb;
  ])  
  AS_IF([test "x$ac_cv_libtokyocabinet" = "xno"],
        AC_MSG_WARN([tokyocabinet not found: not building plugin.]))
DRIZZLED_PLUGIN_DEP_LIBS="${DRIZZLED_PLUGIN_DEP_LIBS} ${LTLIBTOKYOCABINET}"

The above will check for Tokyo Cabinet and whether the TCHDB structure exists. If it doesn’t exist then it will print a warning but if it does exist, it will add the linker option to plugin dependencies. You can now tell the build system to link Tokyo Cabinet, which you do by assigning the LTLIBTOKYOCABINET variable to ldflags in plugin.ini:

ldflags=${LTLIBTOKYOCABINET}

You could directly write “ldflags = -ltokyocabinet” to plugin.ini but you really want to take advantage of configure. configure (more rather autotools) is your friend.

So, this is all I have to cover in this entry and I hope this entry will be helpful to those that are looking into working on a Drizzle plugin. If you would like more information, the Drizzle Wiki should be updated with more detailed explanation soon.

Toru Maesaka drizzle, oss autotools, drizzle, plugin