[Geany-devel] geany-plugins depends on GIO

Colomban Wendling lists.ban at xxxxx
Tue Nov 16 14:13:03 UTC 2010

Le 16/11/2010 09:23, Frank Lanitz a écrit :
> Am 15.11.2010 23:49, schrieb Colomban Wendling:
>> Le 15/11/2010 23:35, Frank Lanitz a écrit :
>>> On Mon, 15 Nov 2010 23:13:31 +0100
>>> Colomban Wendling <lists.ban at herbesfolles.org> wrote:
>>>> Le 15/11/2010 23:06, Frank Lanitz a écrit :
>>>>> On Mon, 15 Nov 2010 22:58:02 +0100
>>>>> Enrico Tröger <enrico.troeger at uvena.de> wrote:
>>>>>> On Mon, 15 Nov 2010 14:04:12 +0100, Colomban wrote:
>>>>>>> Le 30/10/2010 13:20, Frank Lanitz a écrit :
>>>>>>>> On Sat, 30 Oct 2010 13:01:07 +0200
>>>>>>>> Frank Lanitz <frank at frank.uvena.de> wrote:
>>>>>>>>> On Thu, 28 Oct 2010 19:15:14 +0200
>>>>>>>>> Colomban Wendling <lists.ban at herbesfolles.org> wrote:
>>>>>>>>>> PS: make distcheck on geany-plugins doesn't work, fails on
>>>>>>>>>> translation extraction, is it a known issue?
>>>>>>>>> Not yet, will have a look. 
>>>>>>>> OK, well. I guess my knowledge about make is too low here to fix
>>>>>>>> this issue. however, this is the error I can reproduce on my
>>>>>>>> local test system.
>>>>>>>> make[1]: Entering directory
>>>>>>>> `/daten/quellen/git/geany-plugins/geany-plugins/geany-plugins-0.20/_build'
>>>>>>>> Making check in po make[2]: Entering directory
>>>>>>>> `/daten/quellen/git/geany-plugins/geany-plugins/geany-plugins-0.20/_build/po'
>>>>>>>> INTLTOOL_EXTRACT=/usr/bin/intltool-extract
>>>>>>>> srcdir=../../po /usr/bin/intltool-update --gettext-package
>>>>>>>> geany-plugins --pot xgettext: Öffnen der Datei
>>>>>>>> »../../po/../updatechecker/src/updatechecker.c« zum Lesen
>>>>>>>> fehlgeschlagen: Datei oder Verzeichnis nicht gefunden ERROR:
>>>>>>>> xgettext failed to generate PO template file. Please consult
>>>>>>>> error message above if there is any. make[2]: ***
>>>>>>>> [geany-plugins.pot] Fehler 1 make[2]: Leaving directory
>>>>>>>> `/daten/quellen/git/geany-plugins/geany-plugins/geany-plugins-0.20/_build/po'
>>>>>>>> make[1]: *** [check-recursive] Fehler 1 make[1]: Leaving
>>>>>>>> directory
>>>>>>>> `/daten/quellen/git/geany-plugins/geany-plugins/geany-plugins-0.20/_build'
>>>>>>>> make: *** [distcheck] Fehler 1
>>>>>>> I'd better understand with LANG=C :D
>>>>>>> Anyway, I searched a little and found the problem, and it's quite
>>>>>>> simple (no need to be a make guru): updatechecker is not
>>>>>>> integrated with the Autotools build system, so it doesn't get
>>>>>>> into the tarball of make dist. Then, make po fails from this
>>>>>>> tarball because it uses a file that doesn't exist.
>>>>>> Agreed.
>>>>>>> I join 2 patches:
>>>>>>> 1) export GEANY_VERSION so it can be used in plugin's Makefiles
>>>>>> This would make it compiling but not working. At least not as it
>>>>>> should. If the plugin uses the GEANY_VERSION to detect the version
>>>>>> of Geany to check against newer versions, this would mean that it
>>>>>> always checks with a fixed version of Geany: those which was
>>>>>> available at the system where the plugin was compiled. This can be
>>>>>> completely independent from the system where Geany with the plugin
>>>>>> loaded actually runs.
>>>>>> To solve the problem, I think it'd be necessary to read Geany's
>>>>>> version at *runtime* to really get the running version and not the
>>>>>> compiled in GEANY_VERSION macro. To do this, probably a new API
>>>>>> function is necessary (though I didn't really check if it might be
>>>>>> possible already).
>>>>>> I talked with Frank about this already in a private mail, also
>>>>>> joining a patch to integrate it in the autotools build. Now he has
>>>>>> two patches to choose :).
>>>>> Well, I leave it up to you. To be honest I do not care much about
>>>>> as well as I don't have any clue about the autotools-stuff. So I
>>>>> cannot say, what's the best way of solve the issue. 
>>>> I didn't saw Enrico's patch, but as I understand the thing it is more
>>>> about updatechecker code change than autotools stuff.
>>>> My patches only tries to make the plugin compile, and I think, work as
>>>> it would work when compiled with Waf (so "as expected").
>>>> But if the plugin should not use the compile-time Geany version, my
>>>> patches should probably be changed a bit (the first become useless,
>>>> and the second would then have to be updated not to depend on the
>>>> first).
>>>> So... up to you I think :)
>>> Well, I just committed both as they did make sense to me (but in fact,
>>> it was more like rolling dice ...).
>> Well... cool then ^^ Anyway, I'd think that updating Updatechecker to
>> use a runtime Geany version is probably another task than making it
>> compile -- though, it is true that a part of the build system update
>> would be useless after the update.
> Well, agreed. In most cases it should work fine with compiled in version
> number as most cases the API/ABI is changing with some major release.
> But of course this will go into trouble with minor releases as we had
> them with 0.19.1 or if anybody is remembering the 10.x ones :)
> Well, however. I think a simple function which returns the version
> string into plugin API would be enought or am I wrong? something that is
> just doing a return GEANY_VERSION;
I think it is better to return major, minor and micro version (or
something that fits the versionning scheme) as plain integers.
The advantage is that it becomes easy to use this version for any check,
where a string is quite tedious to use.
  geany_get_version(gint *major, gint *minor, gint *micro)
for example, or 3 variables, not sure.

my 2 cents :)

More information about the Devel mailing list