[Geany-devel] geany-plugins depends on GIO
lists.ban at xxxxx
Mon Nov 15 22:13:31 UTC 2010
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: Entering directory
>>>> Making check in po make: Entering directory
>>>> 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: *** [geany-plugins.pot]
>>>> Fehler 1 make: Leaving directory
>>>> make: *** [check-recursive] Fehler 1 make: Leaving directory
>>>> 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.
>>> 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 :)
More information about the Devel