Hi Geany Developers,
I've recently begun packaging the whole set of Geany plugins for Ubuntu (and will be working on it for Debian soon), and Enrico Tröger has mentioned before that he'd like to see the whole set of plugins packaged as one instead of separately, as it is currently. I, too, think it's a good idea to do something like that. However, for that to be done, I'll need the whole geany-plugins tarball released together at once. This has several implications: * Synchronizing the plugins' releases. * There must be a build system capable of building the plugins together as well as separately.
The first, I'll have to leave to the plugin developers to discuss among themselves.
For the second issue, I've noticed that there has been discussion about this before. In that thread, there were two main issues: * large and hard to maintain configure.in file * po/ is required to be in the top level directory by intltool.
For the first issue, I have a solution. Autotools allows you to pass -I<include directory> to aclocal. This can be seen in Banshee[1]'s autogen.sh. This allows you to factor out all the plugin-specific checks into plugin/build/m4/<stuff>.m4 as individual m4 macros, and have one macro per plugin that calls all the plugin-specific checks. This can then be called in the top-level configure.in, as well as each plugin's configure.in.
For the second issue, I think maintaining the plugins' independence is possible if the translations from all plugins are merged into the top-level po/ directory by autogen.sh. This would mean that if the plugins' are built together, GETTEXT_PACKAGE="geany-plugins", whereas if they are built separately, GETTEXT_PACKAGE="$pluginname". Whether or not they are built together would be left up to the user.
That said, I hope to hear positive responses about this matter. =)
Thank you for your time.
[1] http://git.gnome.org/cgit/banshee/tree/autogen.sh
Hi,
On Mon, 01 Jun 2009 15:56:56 +0800 Chow Loong Jin hyperair@gmail.com wrote:
I've recently begun packaging the whole set of Geany plugins for Ubuntu (and will be working on it for Debian soon), and Enrico Tröger has
Cool.
mentioned before that he'd like to see the whole set of plugins packaged as one instead of separately, as it is currently. I, too, think it's a good idea to do something like that. However, for that to be done, I'll need the whole geany-plugins tarball released together at once. This has
I'd really like to see a geany-plugins release, it would be much easier for normal users (and perhaps easier for any plugin maintainers that don't want a separate release as well).
several implications: * Synchronizing the plugins' releases.
geany-plugins SVN trunk is just a place for devs to use, but if someone wanted to be maintainer for a geany-plugins release, perhaps it could go like this:
1. geany-plugins maintainer creates release branch & contacts devs/mailing list 2. Any devs who want their plugin in the release copy/merge their code 3. g-p maintainer makes release X days/weeks after branching
I for one would be happy to merge the GeanyLua plugin.
But this of course requires someone who wants to maintain the geany-plugins release process (any volunteers?) ;-)
* There must be a build system capable of building the plugins together as well as separately.
Does it have to be the same system for both? We have a Waf system for building all plugins, and IIRC it installs translations for each plugin that has them. (Most plugins also have autotools for building individually.)
Regards, Nick
On Tue, 2009-06-02 at 15:08 +0100, Nick Treleaven wrote:
Hi,
On Mon, 01 Jun 2009 15:56:56 +0800 Chow Loong Jin hyperair@gmail.com wrote:
I've recently begun packaging the whole set of Geany plugins for Ubuntu (and will be working on it for Debian soon), and Enrico Tröger has
Cool.
mentioned before that he'd like to see the whole set of plugins packaged as one instead of separately, as it is currently. I, too, think it's a good idea to do something like that. However, for that to be done, I'll need the whole geany-plugins tarball released together at once. This has
I'd really like to see a geany-plugins release, it would be much easier for normal users (and perhaps easier for any plugin maintainers that don't want a separate release as well).
several implications: * Synchronizing the plugins' releases.
geany-plugins SVN trunk is just a place for devs to use, but if someone wanted to be maintainer for a geany-plugins release, perhaps it could go like this:
- geany-plugins maintainer creates release branch & contacts
devs/mailing list 2. Any devs who want their plugin in the release copy/merge their code 3. g-p maintainer makes release X days/weeks after branching
I for one would be happy to merge the GeanyLua plugin.
But this of course requires someone who wants to maintain the geany-plugins release process (any volunteers?) ;-)
I volunteer. =) As it is, I'm working on a patch to get the build system to work both together as well as separately. It's progressing very well, and I've been able to do this for the addons plugin, including automating the toplevel autogen.sh to merge the translations of every plugin into a toplevel po/ directory.
* There must be a build system capable of building the plugins together as well as separately.Does it have to be the same system for both? We have a Waf system for building all plugins, and IIRC it installs translations for each plugin that has them. (Most plugins also have autotools for building individually.)
Personally, from a packager's point of view, I prefer autotools, and if nobody else beats me to it, I will submit a patch that will change modify each plugins' build systems slightly (read: m4 macros, conditional inclusion of the po directory), as well as hook up the build system to the toplevel directory.
In any case, whether or not the patch gets accepted, I will attempt to package the geany plugins for Debian and Ubuntu. If no common release is made, I'll just package them separately.
On Wed, 03 Jun 2009 00:07:48 +0800, Chow wrote:
* There must be a build system capable of building theplugins together as well as separately.
Does it have to be the same system for both? We have a Waf system for building all plugins, and IIRC it installs translations for each plugin that has them. (Most plugins also have autotools for building individually.)
Personally, from a packager's point of view, I prefer autotools, and if nobody else beats me to it, I will submit a patch that will change
I still don't see the need for it. We already have a working build system to build all plugins at once (Waf). So why fiddling with just another one which may introduce new bugs, new problems and of course, more work.
modify each plugins' build systems slightly (read: m4 macros,
See above, why touching the plugins when we already have everything working :(.
conditional inclusion of the po directory), as well as hook up the build system to the toplevel directory.
Hmm, too bad. Frank was working on that on the weekend and he said he got a script working to be used with Waf which merges the plugins' gettext message catalogues into a big global catalogue and vice versa. So, basically it's done, unfortunately he didn't announce it yet so you were probably doing the same thing at the same time.
I'd strongly suggest to talk about and maybe merge your efforts before doing any further coding on this to avoid even more duplicate work!
Regards, Enrico
On Tue, 2 Jun 2009 18:32:14 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 03 Jun 2009 00:07:48 +0800, Chow wrote:
* There must be a build system capable of building theplugins together as well as separately.
Does it have to be the same system for both? We have a Waf system for building all plugins, and IIRC it installs translations for each plugin that has them. (Most plugins also have autotools for building individually.)
Personally, from a packager's point of view, I prefer autotools, and if nobody else beats me to it, I will submit a patch that will change
I still don't see the need for it. We already have a working build system to build all plugins at once (Waf). So why fiddling with just another one which may introduce new bugs, new problems and of course, more work.
modify each plugins' build systems slightly (read: m4 macros,
See above, why touching the plugins when we already have everything working :(.
I agree. For me autotools are always a huge pain with a high violence factor.
conditional inclusion of the po directory), as well as hook up the build system to the toplevel directory.
Hmm, too bad. Frank was working on that on the weekend and he said he got a script working to be used with Waf which merges the plugins' gettext message catalogues into a big global catalogue and vice versa. So, basically it's done, unfortunately he didn't announce it yet so you were probably doing the same thing at the same time.
For now I did a quick'n'dirty shell script as a some kind of proof on concept I'm planning to reimplement with Python hopeful today. In fact it is possible to do the merging stuff in a nice way: 1) To a global file: Put all single po files together into one file and run same steps as in make update-po on it 2) Putting translations back to each plguin: Just cp po files and also run stuff from make update-po on it. I tried it on all plugins and didn't recognised any major issue here. All what is needed is to have some global replacement for POTFILES and LINGUAS which could be also generated from each plugins itself.
Cheers, Frank
On Tue, 2009-06-02 at 19:54 +0200, Frank Lanitz wrote:
I agree. For me autotools are always a huge pain with a high violence factor.
And waf for me. =)
For now I did a quick'n'dirty shell script as a some kind of proof on concept I'm planning to reimplement with Python hopeful today. In fact it is possible to do the merging stuff in a nice way:
- To a global file: Put all single po files together into one file
and run same steps as in make update-po on it 2) Putting translations back to each plguin: Just cp po files and also run stuff from make update-po on it. I tried it on all plugins and didn't recognised any major issue here. All what is needed is to have some global replacement for POTFILES and LINGUAS which could be also generated from each plugins itself.
In response to this, I'll attach the autogen.sh I have currently. It's a modified version of addons/autogen.sh, so if you compare both files, you'll be able to see the parts I've added.
The code I've added into this script generates POTFILES.in, POTFILES.skip, and LINGUAS, as well as merges translations from all .po files from all the plugins specified in the SUBDIRS variable, into the po/ of the toplevel directory.
Chow Loong Jin schrieb:
In any case, whether or not the patch gets accepted, I will attempt to package the geany plugins for Debian and Ubuntu. If no common release is made, I'll just package them separately.
I doubt a big release is nor useful nor feasible in the long run for a growing number of *independent* plugins. That way you need to re-release all plugins if a critical bug was fixed in one, or you wait for the release of 1 plugin to get the whole package released.
Best regards.
Thomas Martitz schrieb:
I doubt a big release is nor useful nor feasible in the long run for a growing number of *independent* plugins. That way you need to re-release all plugins if a critical bug was fixed in one, or you wait for the release of 1 plugin to get the whole package released.
(Pressed Enter too early :( )
I actually think packages each separately, but combine them into such a meta or virtual package (whatever that is called) which is nothing but dependent on all plugins. That way the plugins keep independent but you can still get all plugins in one run.
Best regards.
On Tue, 02 Jun 2009 19:16:29 +0200 Thomas Martitz thomas.martitz@student.HTW-Berlin.de wrote:
I doubt a big release is nor useful nor feasible in the long run for a growing number of *independent* plugins. That way you need to re-release all plugins if a critical bug was fixed in one, or you wait for the release of 1 plugin to get the whole package released.
I don't think it's necessary to wait for a release of a single plugin. Generally plugin releases are already linked to some extent to a Geany release.
(Pressed Enter too early :( )
I actually think packages each separately, but combine them into such a meta or virtual package (whatever that is called) which is nothing but dependent on all plugins. That way the plugins keep independent but you can still get all plugins in one run.
Sounds interesting, but a combined release would be very useful for anyone building from source, plus it gives packagers more freedom - it seems to me that packaging all plugins together would be easier for the packager. Actually a combined release would probably be easier to split the separate plugins from even if doing separate packages.
Not to criticise your idea, just wanted to point out that a combined release is a very useful thing. Also it wouldn't be compulsory for plugin authors ;-)
Regards, Nick
Am 03.06.2009 16:15, schrieb Nick Treleaven:
Sounds interesting, but a combined release would be very useful for anyone building from source,
You can still do a combined release with that metapackage. That's why desktop enviroments are distrubuted via meta packages in debian/ubuntu. Installing gnome-desktop-environment installs a shit load of partly faked(!) dependencies to get you the whole DE. Yet, if you want, you can install each dependency on its own and leaving those you don't need out (like evolution or ephany). The point is, with every gnome release the meta package is updated and all dependencies will be updated too.
plus it gives packagers more freedom - it seems to me that packaging all plugins together would be easier for the packager.
I can't connect both phrases. More freedom in packaging generally means more work if the freedom wants to be kept. And saving work by putting all plugins into one package surely doesn't extend the freedom of anyone.
Actually a combined release would probably be easier to split the separate plugins from even if doing separate packages. Not to criticise your idea, just wanted to point out that a combined release is a very useful thing. Also it wouldn't be compulsory for plugin authors ;-)
See above :)
Best regards.
On Wed, 03 Jun 2009 18:54:35 +0200 Thomas Martitiz s0523936@htw-berlin.de wrote:
Sounds interesting, but a combined release would be very useful for anyone building from source,
You can still do a combined release with that metapackage. That's why
I should have been clearer. When I said release, I was talking about the source tar.gz release, not packages. I understand the meta-package idea, sounds good.
plus it gives packagers more freedom - it seems to me that packaging all plugins together would be easier for the packager.
I can't connect both phrases. More freedom in packaging generally means more work if the freedom wants to be kept. And saving work by putting all plugins into one package surely doesn't extend the freedom of anyone.
I wasn't talking about user's freedom ;-)
I meant more generally about packagers on all different distros, that it would probably be easier for a packager to just make one geany-plugins package, which would be really awkward to maintain without a central geany-plugins source release.
Individual packages are fine though, just wanted to mention that not all distros would want to maintain them.
Regards, Nick