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@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@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@frank.uvena.de wrote: > >> On Thu, 28 Oct 2010 19:15:14 +0200 >> Colomban Wendling lists.ban@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:
- 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;
Cheers, Frank