[Geany-devel] Plugins build system
enrico.troeger at xxxxx
Thu Jun 5 15:51:13 UTC 2008
some time ago, I played a little bit with autotools just to test about a
common build system for the plugins project.
First it was easier than I expected but it's still not working as I'd
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.
But once we want to include gettext support it's going to be tricky.
To get gettext support working, we need the GETTEXT_PACKAGE variable in
config.h, set by the configure script. And we need to create a
po/Makefile for each plugin. But both doesn't work with the top-level
Each plugin uses the created config.h in the top-level directory
because in the plugin's directory there is none.
So GETTEXT_PACKAGE would be the same for all plugins.
We could simply skip all gettext support for the build system, then
most things are already done.
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.
I also tried some experiements with some kind of a shared po directory
but all tries failed badly. Either I got build errors or endless loops
in make or even worse problems.
After all, I definetely won't work on a common build system based on
autotools. Maybe I just did something wrong, but it's to hard to find
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
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.
What do you think?
Get my GPG key from http://www.uvena.de/pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Devel