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 :).
Regards, Enrico