Hey,
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 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.
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 configure script. 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 out.
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.
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?
Regards, Enrico