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
On Thu, 5 Jun 2008 17:51:13 +0200 Enrico Tröger enrico.troeger@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 plugin.
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 makefile.win32's.
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.
Regards, Nick
On Fri, 6 Jun 2008 13:28:03 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
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.
audacious-plugins (http://audacious-media-player.org/index.php?title=Downloads) does this, a single configure.ac. It has separate arguments for plugins, like --enable-esd. It doesn't use
It also uses buildsys to generate the autotools files: http://sourceforge.net/projects/buildsys
I couldn't find much descriptive info about it, but it seems to be like wxWidgets' Bakefile system. The advantage of this is that users can have less dependencies - e.g. just use a free IDE to build on Windows, but I'm not sure if it would help in our case.
Mainly I just wanted to mention that it uses a unified configure script, and a common po/ directory.
Regards, Nick
Hi
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.
One configure.in is not very good solution, IMHO.
While it is good that geany depend only on GTK+, such restriction not good for plugins.
This single configure script will be VERY complex (probably hard to maintain) because different plugins depend on different libraries: lua, python, ruby, gnome, kde, oracle etc. It is expected that some plugins will not compile on all platform, also it is expected that some libraries can't be linked together with other.
Best regards, Yura Siamashka
On Fri, 6 Jun 2008 16:26:21 +0300, "Yura Siamashka" yurand2@gmail.com wrote:
Hi
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.
One configure.in is not very good solution, IMHO.
While it is good that geany depend only on GTK+, such restriction not good for plugins.
This single configure script will be VERY complex (probably hard to maintain) because different plugins depend on different libraries:
And it probably takes hours to finish :D.
Regards, Enrico
On Fri, 6 Jun 2008 15:30:25 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Fri, 6 Jun 2008 16:26:21 +0300, "Yura Siamashka" yurand2@gmail.com wrote:
This single configure script will be VERY complex (probably hard to maintain) because different plugins depend on different libraries:
And it probably takes hours to finish :D.
The tests for library dependencies don't take long, pkg-config is very fast. And it would be a *lot* faster than running one configure script per plugin.
Regards, Nick
On Fri, 6 Jun 2008 16:26:21 +0300 "Yura Siamashka" yurand2@gmail.com wrote:
Hi
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.
One configure.in is not very good solution, IMHO.
While it is good that geany depend only on GTK+, such restriction not good for plugins.
This single configure script will be VERY complex (probably hard to maintain) because different plugins depend on different libraries:
As I mentioned, this is already done for audacious-plugins, and IIRC for Pidgin, and I expect other plugin projects too. If anyone is aware of other projects that do this differently, please let us know.
One thing that might be confusing - a geany-plugins build system would only be for plugins that want to use it - if you just want SVN, there would be no need to use anything above your plugin's directory.
lua, python, ruby, gnome, kde, oracle etc. It is expected that some plugins will not compile on all platform, also it is expected that some libraries can't be linked together with other.
You could write the configure script so if Lua is not installed, just don't build the Lua plugin, and so on.
Regards, Nick
On Fri, 6 Jun 2008 13:28:03 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 5 Jun 2008 17:51:13 +0200 Enrico Tröger enrico.troeger@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
This would mean every plugin loose it's own (autotools) build system and so they loose some of their independence. Might be not a problem, but maybe though.
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
With your approach, it is not possible to use single translation catalogs the resulting po files for each plugin, AFAIK. Using a single top-level configure.in would mean that we have only one top-level po dir, with one catalog for all plugins. But after all, this is a big advantage as it eases maintainability and especially heavily reduces the necessary work of translators as there is only one file to translate. (assuming loosing plugin's independence is not a problem)
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.
I think the message catalogs aren't a real problem for distros but rather the plugin's dependencies. In Debian, maintainers recently solved such issues in some packages with some kind of soft dependencies. The package itself doesn't depend on all necessary libs for each plugin, only for the really necessary ones. For instance, a geany-plugins package in Debian would depend on GTK and Geany, as these are essentially necessary (obviously). But the package would not depend on gtkspell (geanyvc plugin) or aspell (spellcheck plugin). Instead the package only "suggests" these dependencies to tell the user there are dependencies which are necessary to get everything fully working. As long as gtkspell isn't installed the geanyvc wouldn't load in Geany but Geany as well as the other plugins are not affected by this and so working as usual. Maybe the geanyvc plugin is not the best example as the gtkspell dependency is optional but I think it's clear enough. No idea how other distros handle this.
@Damián, correct me if I'm wrong :D.
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
I never wanted to say, we *will* use Waf or anything else which would need many dependencies. I just like Waf and I mentioned it as an example. And I agree, autotools are generally good in portability issues and finding workarounds for differences on different platforms. Anyway, it's still not nice to use.
it. I'm guessing it also depends on a Bourne shell, so with Python as
I don't think it depends on any shell, I guess it's all done with Python internals.
well it adds another barrier to Windows development - I think if we
I actually didn't use Python on Windows yet but I don't think it's a real barrier. The real barrier on Windows is mingw and everything around, read: a build environment. But except we start to use Visual Studio or something, we won't get around this. It's Windows.
Another issue is portability to non-Linux systems - autotools is a good choice for this reason because it is well documented and for
I hate its documentation but that's another topic :D.
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.
Most other build systems do this as well (cmake, scons, ...).
To sum it up: I'm not against any autotools based solution, I just won't work it myself.
Regards, Enrico
On Fri, 6 Jun 2008 15:31:38 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Fri, 6 Jun 2008 13:28:03 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
...
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
This would mean every plugin loose it's own (autotools) build system and so they loose some of their independence. Might be not a problem, but maybe though.
But only plugins that wanted to use a common build system would use it, it wouldn't affect those that just wanted SVN. It's only useful so we could do official geany-plugins releases.
If we did a geany-plugins release, we could make a release branch, named after the Geany version it's compatible with, and only include plugins that want the common build system in the .tar.gz.
...
With your approach, it is not possible to use single translation catalogs the resulting po files for each plugin, AFAIK. Using a single
Yes, that's what I intended for plugins wanting a common build system.
top-level configure.in would mean that we have only one top-level po dir, with one catalog for all plugins. But after all, this is a big advantage as it eases maintainability and especially heavily reduces the necessary work of translators as there is only one file to translate. (assuming loosing plugin's independence is not a problem)
If independence is wanted - e.g. for a plugin that is unusually large or has a specific niche appeal - e.g. for a certain programming language, then I would recommend it just didn't use the common build system.
...
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.
I think the message catalogs aren't a real problem for distros but rather the plugin's dependencies. In Debian, maintainers recently solved such issues in some packages with some kind of soft dependencies. The package itself doesn't depend on all necessary libs for each plugin, only for the really necessary ones. For instance, a geany-plugins package in Debian would depend on GTK and Geany, as these are essentially necessary (obviously). But the package would not depend on gtkspell (geanyvc plugin) or aspell (spellcheck plugin). Instead the package only "suggests" these dependencies to tell the user there are dependencies which are necessary to get everything fully working. As long as gtkspell isn't installed the geanyvc wouldn't load in Geany but Geany as well as the other plugins are not affected by this and so working as usual. Maybe the geanyvc plugin is not the best example as the gtkspell dependency is optional but I think it's clear enough. No idea how other distros handle this.
Hmm, I hadn't thought about this - I think having extra plugins depend on geany-plugins is OK though. It would be wise to keep any plugins with unusual dependencies out of the common build system though.
...
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
I never wanted to say, we *will* use Waf or anything else which would need many dependencies. I just like Waf and I mentioned it as an example. And I agree, autotools are generally good in portability issues and finding workarounds for differences on different platforms. Anyway, it's still not nice to use.
it. I'm guessing it also depends on a Bourne shell, so with Python as
I don't think it depends on any shell, I guess it's all done with Python internals.
OK, maybe. I guess there must be a way to set CFLAGS on the Windows command prompt ;-)
well it adds another barrier to Windows development - I think if we
I actually didn't use Python on Windows yet but I don't think it's a real barrier. The real barrier on Windows is mingw and everything around, read: a build environment. But except we start to use Visual Studio or something, we won't get around this. It's Windows.
Yes, we can't get around it. I guess Python isn't more difficult than MSYS to install. Probably easier, but bigger.
Another issue is portability to non-Linux systems - autotools is a good choice for this reason because it is well documented and for
I hate its documentation but that's another topic :D.
Well, it's documented in howtos outside the official docs as well.
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.
Most other build systems do this as well (cmake, scons, ...).
I thought one of the major speed slowdowns in running configure were all the compiling tests that are needed to see if libc/cc works as expected. But I haven't tried the other systems.
To sum it up: I'm not against any autotools based solution, I just won't work it myself.
Fair enough, but I think it's probably the best choice.
Regards, Nick
On Fri, 6 Jun 2008 17:20:35 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
On Fri, 6 Jun 2008 15:31:38 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
...
To sum it up: I'm not against any autotools based solution, I just won't work it myself.
Fair enough, but I think it's probably the best choice.
It seems no one else agrees with me about the common configure script ;-)
I was thinking, probably anything is better than nothing, so perhaps committing the configure script you wrote that just calls the subdirectory configures would be useful. If you want to write a waf system this would be useful too. I assume most linux devs have python anyway.
Regards, Nick
On Tue, 10 Jun 2008 12:49:34 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Fri, 6 Jun 2008 17:20:35 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
On Fri, 6 Jun 2008 15:31:38 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
...
To sum it up: I'm not against any autotools based solution, I just won't work it myself.
Fair enough, but I think it's probably the best choice.
It seems no one else agrees with me about the common configure script ;-)
I was thinking, probably anything is better than nothing, so perhaps committing the configure script you wrote that just calls the subdirectory configures would be useful. If you want to write a waf
I'm not sure, it is really not very good and definetely needs a lot of love. Anyway, I committed the files but it is not even working because the Makefile.am's of the plugin directories contain SUBDIRS = po ... but there are no Makefile.* in the various plugin directories as their creation is currently disabled in the configure.in. To not attempt users to use this, I moved the files into the directory 'buildtest'. For actual testing, they should be moved in the toplevel directory above.
subdirectory configures would be useful. If you want to write a waf system this would be useful too. I assume most linux devs have python anyway.
Yes, I will do this, at some point. Not in the next days :D.
Regards, Enrico