[Geany-devel] Plugins build system

Fri Jun 6 13:31:38 UTC 2008

On Fri, 6 Jun 2008 13:28:03 +0100, Nick Treleaven
<nick.treleaven at btinternet.com> wrote:

> 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

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

-- 
Get my GPG key from http://www.uvena.de/pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20080606/7cdac5b7/attachment.pgp>