[Geany-devel] Plugins build system

Nick Treleaven nick.treleaven at xxxxx
Fri Jun 6 12:28:03 UTC 2008

On Thu, 5 Jun 2008 17:51:13 +0200
Enrico Tröger <enrico.troeger at uvena.de> wrote:

> Hey,
> some time ago, I played a little bit with autotools just to test
> about a common build system for the plugins project.

Great, I think we need this.

> First it was easier than I expected but it's still not working as I'd
> wish.
> Basically it's enough to create a simple configure.in and list the
> plugins' makefiles in it. autogen.sh does the rest by walking any
> subdirectories and init them if there is a configure.in is found.
> Then the configure script is created in the top level directory and it
> works fine, make will then build each plugin below.
> So far it's pretty cool.

Hmm, I wonder what other projects do.

One thing I've thought about is just to have a single configure.in for
all plugins, with some way to tell ./configure which plugins to build,
perhaps a way to only build one or a named set to build. This might
have the advantage of a single config.h and translation support. The
disadvantage might not be important - that to build you have to have
all the plugins on disk, you can't just checkout a single plugin
folder. If you have an option like
--enable-plugins='spellcheck,geanydoc', this might not be a problem.

> Or we use a global gettext infrastructure for all plugins and add
> every source file to po/POTFILES.in. This would solve the problem and
> had the advantage that translators need only one file to translate
> containing the strings of all plugins.
> The down side of this is that plugins loose their gettext support when
> build alone or they have to manage a separate message catalog.

With my approach probably the translations would all have to be
installed even for only one plugin, but if it was in a common
place, geany-plugins.mo, then there wouldn't be duplicates if further
plugins were then installed. This might limit what packaging of plugins
can be done, but probably a distro could just say some big plugin that
should be separate depends on the geany-plugins package, which has the
message catalogs for it. Or even have a common message catalog for most
plugins, and any that want a separate one can do so, just don't add to
the common POTFILES.in.

> Two other suggestions:
> a) use a simple Makefile in the top level directories which simply
> iterates over plugins' directories and calls make && make install, if
> necessary it calls configure before directly in the plugin's
> directory. So, we would use the build system of each plugin and more
> or less just iterate over available plugins.
> This is easy to implement and should work. But you have to run
> the configure script for each plugin at least everytime configure.in
> has changed.

Yes, this is slow for the case where users just want to build every

> b) use another build system independent from plugins' build system.
> I'd suggest Waf as I like it but maybe something else is better
> suited. This could be realised quite clean and plugins doesn't need
> to be changed but every none standard requirement of a single plugin
> (e.g. library dependencies like aspell for the spellcheck plugin) has
> to be maintained separately in this build system.

I feel cautious about using something other than autotools. Yes, it's
ugly. But Python is quite a big dependency for a lightweight
application - although users installing binary packages wouldn't need
it. I'm guessing it also depends on a Bourne shell, so with Python as
well it adds another barrier to Windows development - I think if we
are considering other build systems we should bear in mind Windows -
for geany-plugins it would be difficult to get all plugins to write

Another issue is portability to non-Linux systems - autotools is a good
choice for this reason because it is well documented and for problems
like linking the socket library on Solaris, the solution can be found
quite easily just by searching the net. Also probably there are libc
problems that autotools works around.

Obviously I don't like autotools, it's slow and ugly, but it's very
difficult to replace without causing other problems like additional
dependencies, or just the difficulty of getting people to learn it.
With autotools you can often just see how a similar project did it.


More information about the Devel mailing list