[Geany-devel] Plugins build system

Nick Treleaven nick.treleaven at xxxxx
Fri Jun 6 16:20:35 UTC 2008

On Fri, 6 Jun 2008 15:31:38 +0200
Enrico Tröger <enrico.troeger at uvena.de> wrote:

> On Fri, 6 Jun 2008 13:28:03 +0100, Nick Treleaven
> <nick.treleaven at 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

> > 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.


More information about the Devel mailing list