Difference between revisions of "Build system"

From collectd Wiki
Jump to: navigation, search
(Undo revision 1992 by 62.80.184.178 (Talk))
(→‎autoconf)
Line 3: Line 3:
 
Starting with [[Version 4.1]] the dependency checking is done in the ''configure'' script with version 4.1. The plugins are automatically enabled or disabled, depending on whether their dependencies are met (or not) and the <code>--enable-plugin</code> argument can be used to ''force'' the plugin to be enabled or disabled.
 
Starting with [[Version 4.1]] the dependency checking is done in the ''configure'' script with version 4.1. The plugins are automatically enabled or disabled, depending on whether their dependencies are met (or not) and the <code>--enable-plugin</code> argument can be used to ''force'' the plugin to be enabled or disabled.
  
−
== autoconf ==
+
Wow! That's a really neat awnesr!
−
 
 
−
The first step to include your plugin in the build process is to add it to the ''configure'' script. To do so, edit the {{GitFile|configure.in}} file. You'll need to add a line with the <code>AC_PLUGIN</code> macro that will add:
 
−
 
 
−
* the <code>--enable-plugin</code> argument to the ''configure'' script,
 
−
* the <code>BUILD_PLUGIN_PLUGIN</code> conditional to the Makefile, and
 
−
* the <code>HAVE_PLUGIN_PLUGIN</code> define to config.h.
 
−
 
 
−
The macro needs to be called like this:
 
−
AC_PLUGIN([name], $with_dependency, [description])
 
−
 
 
−
The second argument is the value of a variable which decides whether the plugin should be built or not. If your plugin does not have any dependencies outside of C99&nbsp;/ POSIX, you can simply pass <code>"yes"</code> here. Otherwise, determining if a dependency is present is, of course, the tricky part. The variable <code>$with_dependency</code> should be set to <code>"yes"</code> if the dependency is met and anything else otherwise. The first argument is simply the name of the plugin, the third is only a description for
 
−
./configure --help
 
−
 
 
−
It's probably a good idea to just search for the macro and copy one of the existing lines. If you plan on [[Submitting patches|sending your patch]] to the [[mailing list]], please note that the plugins are sorted alphabetically.
 
  
 
== automake ==
 
== automake ==

Revision as of 06:34, 29 April 2011

This page described collectd's build system, which is based on autoconf and automake.

Starting with Version 4.1 the dependency checking is done in the configure script with version 4.1. The plugins are automatically enabled or disabled, depending on whether their dependencies are met (or not) and the --enable-plugin argument can be used to force the plugin to be enabled or disabled.

Wow! That's a really neat awnesr!

automake

The AC_PLUGIN macro (see above) sets a conditional to be used in src/Makefile.am, the input files for automake. There are multiple Makefile.am's, one in each directory. If you want to add your own plugin to src/, the on in that directory is the one you need to edit. The conditionals are named BUILD_PLUGIN_PLUGIN. Conditionals are similar to #ifdef preprocessor statements in C: They surround the block that defines the plugin so that it's only build if the conditional is true. A typical block looks like this: 

if BUILD_PLUGIN_FOOBAR
pkglib_LTLIBRARIES += foobar.la
foobar_la_SOURCES = foobar.c
foobar_la_LDFLAGS = -module -avoid-version
collectd_LDADD += "-dlopen" foobar.la
collectd_DEPENDENCIES += foobar.la
endif

Again, your best bet is to copy an existing block and adapt it to your needs.

Generating configure and Makefile.in

After you have made your changes you need to generate the configure-script and some Makefile.in's. This can be done by simply typing make if you already have a configure script (the generated Makefile will check if it needs to re-generate the auto{conf,make} stuff) or by running the build.sh script from the Git repository. After that you should be ready to go.

Retrieved from "https://collectd.org/wiki/index.php?title=Build_system&oldid=3254"