#include <gcoonf/gconf-client.h> geht nicht!

[juedan]

Guten Morgen,

ich will es kurz machen, weil ich müde bin!
Seit gestern Abend 8.00 Uhr sitze ich hier und versuche mit google, mehreren hundert Seiten Doku-Ausdrucken und unserem Chef-Programmierer das nächste Problem zu lösen:
Im main-header-file unseres Projektes steht folgende Zeile:

#include <gconf/gconf-client.h>

In die Datei configure.in wurde - wie es lt. Dokumentation und google angeraten ist - folgender Ausdruck eingefügt:
AM_GCONF_SOURCE_2

Nach einem

$ rm .rf configure config.h.in autom4te.cache
$ ./autogen.sh
$ make

erhalten wir immer nur, dass die das o.g. include-file nicht gefunden werden kann.
Das include-file ist selbstverständlich vorhanden:
/usr/X11R6/include/gconf/1/gconf
bzw.
/usr/X11R6/include/gconf/2/gconf

Was muß in welche Datei wo eingetragen werden, damit make dieses include-file findet. Mir reicht es langsam, meine Freundin ist stinksauer, weil ich wieder ein WE für die Firma opfern muß, nur weil in keiner Doku irgendwas erwähnt wird.
Übrigens google ist da auch keine Hilfe, weil offensichtlich die betreffende Leute auch weiter wissen. Ich bin sauer und hunde-müde.

Bitte keine von diesen Antworten wie "steht doch in der Doku".
Falls ja, dann bitte mit exakter Quellenangabe!

Viele Grüße und vielen Dank schon mal für die Antworten.

Jürgen

 

[[tE]bachi]

Ich kenn mich auch nicht so aus mit den GNU AutoTools, aber bei mir funktioniert es soweit:

configure.ac

PKG_CHECK_MODULES(DEPS, gconf-2.0 >= 2.8)
AC_SUBST(DEPS_CFLAGS)
AC_SUBST(DEPS_LIBS)

Makefile.am

mein_prog_LDAD      = $(DEPS_LIBS)
AM_CPPFLAGS         = $(DEPS_CFLAGS)

Aber du musst dich schon entscheiden, ob du lieber bei der Freundin bist, oder programmierst. Beides ist sehr Zeitaufwändig, braucht viel Geduld und macht manchmal auch extrem Nerven.

greets

[tE]bachi

 

[juedan]

Hallo,

Ich kenn mich auch nicht so aus mit den GNU AutoTools, aber bei mir funktioniert es soweit:

configure.ac

PKG_CHECK_MODULES(DEPS, gconf-2.0 >= 2.8)
AC_SUBST(DEPS_CFLAGS)
AC_SUBST(DEPS_LIBS)

Wo ist das beschrieben? Das haben wir bei der ganzen "Googlerei" nirgends gefunden.

Aber du musst dich schon entscheiden, ob du lieber bei der Freundin bist, oder programmierst. Beides ist sehr Zeitaufwändig, braucht viel Geduld und macht manchmal auch extrem Nerven.

greets

[tE]bachi

Da ist schon klar. Ich entwickle schon seit fast 10 Jahren Software im kommerzeillem Umfeld. Die Schwierigkeiten und Komplexitäten bei der Erstellung von GTK/GNOME-Programmen sind schon aussergewöhnlich.
Selbst großen Windows-Software-Pakete, die oft genug erstellt habe, haben nicht einen solchen bürokratischen Aufwand...

Viele Grüße und danke für den Hinweis.

Jürgen

 

[[tE]bachi]

Wo ist das beschrieben? Das haben wir bei der ganzen "Googlerei" nirgends gefunden.

Schon ausprobiert?
PKG_CHECK_MODULES ist ein Zusatzmakro,
das nicht bei der Grundinstallation von den
GNU AutoTools dabei ist. Durch das Packet
'pkg-config' wurde dies dazuinstalliert.
Habe vor ein paar Monaten auch meine
ersten Schritte mit GNU AutoTools mit
GNOME und i18n gemacht und habe ein
gutes, aber ein bisschen veraltetes, Tutorial
gefunden, das auch das Makro enthält:
GTK Hello World, Internationalized

Da ist schon klar. Ich entwickle schon seit fast 10 Jahren Software im kommerzeillem Umfeld. Die Schwierigkeiten und Komplexitäten bei der Erstellung von GTK/GNOME-Programmen sind schon aussergewöhnlich.
Selbst großen Windows-Software-Pakete, die oft genug erstellt habe, haben nicht einen solchen bürokratischen Aufwand...

Nach einem Seitenblick auf dein Profil sehe
ich, das du schon 38 Jahre alt bist. Ist ein
bisschen alt um neue APIs zu büffeln. Aber
was macht man alles, um endlich von
Micro$oft Windows loszukommen. Ich
bewundere das... Wenn du nicht viel
"bürokratie" und performanz willst, wechste
auf Java und GTK+ Bindung. Ist einfachen,
aber nicht mehr so performant.
Ist es aber nicht an der Zeit, eine Familie zu
gründen, viele kleine Kinder zu zeugen und
nicht mehr immer den neusten APIs hinterher
zu rennen? Eine Freundin hast du ja, oder?
Überlegs dir mal...

greets

[tE]bachi

 

[juedan]

Schon ausprobiert?
PKG_CHECK_MODULES ist ein Zusatzmakro,
das nicht bei der Grundinstallation von den
GNU AutoTools dabei ist. Durch das Packet
'pkg-config' wurde dies dazuinstalliert.
Habe vor ein paar Monaten auch meine
ersten Schritte mit GNU AutoTools mit
GNOME und i18n gemacht und habe ein
gutes, aber ein bisschen veraltetes, Tutorial
gefunden, das auch das Makro enthält:
GTK Hello World, Internationalized

Ja jetzt geht es - endlich.
Danke für den Link. Den werde ich mir morgen in der Mittagspause mal reinziehen.

Nach einem Seitenblick auf dein Profil sehe
ich, das du schon 38 Jahre alt bist. Ist ein
bisschen alt um neue APIs zu büffeln.

Wenn man ca. 10 Jahre lang eine eigene Firma gehabt hat, ist man gewohnt über den Tellerrand hinauszusehen und dies und jenes kennenlernen zu müssen.

Eigentlich arbeite ich als Sysadmin. Aber das Projekt soll sowohl auf Windows-Systemen als auch auf Unix-Systemen funktionieren. Da ich der einzige in der Firma bin der sich mit beidem auskennt (Unix und C-Programmierung), hat man die Aufgabe der Windoof->Unix-Portierung vertrauensvoll in meine Hände gelegt .

Aber
was macht man alles, um endlich von
Micro$oft Windows loszukommen. Ich
bewundere das... Wenn du nicht viel
"bürokratie" und performanz willst, wechste
auf Java und GTK+ Bindung.

Java - schüttel und Krämpfe.

Ist es aber nicht an der Zeit, eine Familie zu
gründen, viele kleine Kinder zu zeugen und
nicht mehr immer den neusten APIs hinterher
zu rennen? Eine Freundin hast du ja, oder?
Überlegs dir mal...

Mit diesem Ratschlag kommst Du gut sieben Monate zu spät - Mitte Mai soll es soweit sein (ich werde berichten).

Viele Grüße

Jürgen

 

[juedan]

Hallo [tE]bachi

Habe vor ein paar Monaten auch meine
ersten Schritte mit GNU AutoTools mit
GNOME und i18n gemacht und habe ein
gutes, aber ein bisschen veraltetes, Tutorial
gefunden, das auch das Makro enthält:
GTK Hello World, Internationalized

Das Beispiel-Programm funktioniert nicht!

Sobald in ich das Verzeichnis "po" wechsle und dort "make update-po" ausführe bekomme ich diese Fehlermeldung:

make hello.pot
make: don't know how to make hello.pot. Stop
*** Error code 2

Stop in /home/devel/Projekte/hello/po.

So! Und werde mir jetzt etwas anderes überlegen, wie man der Internationalisierung Herr werden kann.

Viele Grüße und schönes Osterfest

Jürgen

 

[razoredge]

Hallo [tE]bachi

Das Beispiel-Programm funktioniert nicht!

Sobald in ich das Verzeichnis "po" wechsle und dort "make update-po" ausführe bekomme ich diese Fehlermeldung:

make hello.pot
make: don't know how to make hello.pot. Stop
*** Error code 2
Stop in /home/devel/Projekte/hello/po.

BSD make != GNU make. Versuch's mal mit gmake.

So! Und werde mir jetzt etwas anderes überlegen, wie man der Internationalisierung Herr werden kann.

Das hatte ich auch (mal) gehofft, leider ist i18n mit gettext immer noch simpler als Alternativloesungen, bei denen aufwendige locale-Auswertungen, regionale codes, usw. behandelt werden muessen. Auch wenn es ziemlich bescheiden zu implementieren ist (libintl extern vs. intl in (g)libc vs. eigene intl-Impementationen, etc.pp.).

gruss

 

[juedan]

Hallo razoredge,

BSD make != GNU make

Ich dachte mit diesem ganzen auto*-Kram soll eine Plattform-Unabhängigkeit gewährleistet sein?

Ach ja, es geht einfacher:
Du wirst OS/2 wahrscheinlich nicht aus Programmierersicht kennen. Dort gab es einen sogenannten "resource-compiler". Mit dem konnte man u.a. String-Resourcen (Dateiaufbau: string-id string) kompilieren und zum Programm linken. So ähnlich wie dieses gettext-Monster.
Man konnte mit dem Resourcen-Compiler auch eine DLL erzeugen, die dann zur Laufzeit eingebunden wurde. Eine Sprachunabhängigkeit wurde dadurch gewährlistet, dass man am Anfang des Programms, die Sprachumgebung abgefragt und dann die entsprechende DLL gezogen hatte. Minimaler Aufwand und wesentlich einfacher.

Man konnte bei der Installation des Programms die entsprechende "Sprach-DLL" linken und gut wars.

Allein für mein Programm gPowershot ist das configure-Skript 13865 Zeilen lang...
Das Projekt in der Firma hat auch ein ähnlich großes configure-Skript.

Viele Grüße

Jürgen

 

[razoredge]

Ich dachte mit diesem ganzen auto*-Kram soll eine Plattform-Unabhängigkeit gewährleistet sein?

Ja, das schliesst aber nicht die Werkzeuge ein. Die Autotools erzeugen Makefiles fuer GNU make, welches von etlichen Plattformen unterstuetzt wird.

Man konnte mit dem Resourcen-Compiler auch eine DLL erzeugen, die dann zur Laufzeit eingebunden wurde. Eine Sprachunabhängigkeit wurde dadurch gewährlistet, dass man am Anfang des Programms, die Sprachumgebung abgefragt und dann die entsprechende DLL gezogen hatte. Minimaler Aufwand und wesentlich einfacher.

Was auch noch bestens funktioniert, wenn die strings auf *BSD, *Linux, $SYSTEM ausgegeben werden sollen? Nicht? Och, schade ;-).

gettext erzeugt Dateien, welche ohne Probleme auf jedem System verwendet werde koennen, das gettext unterstuetzt. Ohne Neulinken oder aehnlichen Kram (lediglich das Programm muss uebersetzt werden, damit es laeuft, nicht aber die Dateien neu generiert werden, siehe dazu auch die recht ausfuehrliche gettext-Beschreibung).

Allein für mein Programm gPowershot ist das configure-Skript 13865 Zeilen lang...
Das Projekt in der Firma hat auch ein ähnlich großes configure-Skript.

Das ist normal, da die autotools verschiedenste (aufwendig zu behebende) Sonderfaelle, Shellvarianten und Testfaelle beachten sollen/wollen. Dafuer muss entsprechender Code erzeugt werden. Hinzu kommt, dass das ganze auch noch moeglichst plattformunabhaengig sein soll, was zur Folge hat, dass sich stark an der sh-Syntax orientiert wird (ergo: mehr Code als z.B. unter der Bash mit ihren Moeglichkeiten).

Es stoert viele (inklusive mir), aber derzeit gibt es keine _wirklich_ vergleichbare Alternative, welche auch noch mit unterschiedlichsten Programmarten und Systemtypen umgehen kann.

gruss

 

[juedan]

Hallo,

Es stoert viele (inklusive mir), aber derzeit gibt es keine _wirklich_ vergleichbare Alternative, welche auch noch mit unterschiedlichsten Programmarten und Systemtypen umgehen kann.

Wenn es wenigesten sauber dokumentiert wäre.
Auf meinem Schhreibtisch liegen zum Thema acht (!!!) verschiedende Dokus. Keine funktioniert, nicht mal die aus dem teuren Buch (¤40,-) von Herrn Warkus.

Wo gibt es eine Dokumentation, die auch mal Fehlermeldungen beschreibt(!!!) und die das BSD-make benutzt. Und was auch ganz wichtig ist: die ein FUNKTIONIERENDES Beispiel enthält, damit man den Mechanismus auch mal verstehen kann.
Solange ich die nicht habe, werde ich meine Programme in drei Sprachen anbieten können: deutsch, spanisch und englisch.

Viele Grüße

Jürgen

 

[razoredge]

[...]
Wo gibt es eine Dokumentation, die auch mal Fehlermeldungen beschreibt(!!!) und die das BSD-make benutzt. Und was auch ganz wichtig ist: die ein FUNKTIONIERENDES Beispiel enthält, damit man den Mechanismus auch mal verstehen kann.
Solange ich die nicht habe, werde ich meine Programme in drei Sprachen anbieten können: deutsch, spanisch und englisch.

BSD-make und autotools? Da kannst Du lange suchen. Die sind fuer GNU ausgelegt und damit hat es sich. Ich habe noch keine Unterstuetzung fuer BSD-make gefunden (insbesondere fuer (Free)BSDs Sonderbehandlung von gettext, bei der immer alles nicht so laeuft wie von den GNUlern geschrieben).

Ansonsten kann ich Dir (fuer den Einstieg) eigentlich nur folgende Links empfehlen:

http://sources.redhat.com/autobook/
http://seul.org/docs/autotut/

Desweiteren gilt: Scripte anderer Projekte lesen, versuchen zu verstehen, zu adaptieren. Traurig, aber wahr...

Als Alternative koennte ich Dir noch toc ans Herz legen, welches zumindest (nur) mit der Bash recht gut funktioniert (auch wenn es sich vom Funktionsumfang mit den autotools nicht messen kann). Es ist jedoch leichter zu konfigurieren, wenn man sich mit der Shellprogrammierung auskennt:

http://toc.sourceforge.net/

gruss

 

[[tE]bachi]

mit i18n habe ich auch mehrere tage verbracht.
hier ein ausschnitt aus configure.ac

[...]

dnl === gettext ===========================================

ALL_LINGUAS="en de"
AM_GLIB_GNU_GETTEXT
GETTEXT_PACKAGE=$PACKAGE
AC_SUBST(GETTEXT_PACKAGE)
AC_DEFINE_UNQUOTED([GETTEXT_PACKAGE], ["${GETTEXT_PACKAGE}"], [gettext domain])

dnl === libintl ===========================================

AC_PROG_INTLTOOL(0.22, no-xml)
AC_CHECK_LIB(intl, main, [], AC_MSG_ERROR("no intl library found"))
AC_CHECK_HEADER(libintl.h, [], AC_MSG_ERROR("no intl header found"))

[...]

bei freebsd musst du beim ausführen von configure noch ein paar umgebungs variablen definieren. ich habe dafür ein autogen.sh erstellt:

#!/bin/sh


case $1 in
    auto)
        aclocal15
        intltoolize --copy --force --automake
        autoheader253
        autoconf253
        automake15 --add-missing --copy
        ;;
    
    config)
        CPPFLAGS="-I/usr/local/include" \
        LDFLAGS="-L/usr/local/lib -lintl" \
        ./configure --prefix=/usr/home/bachi/Nemo-Test
        ;;
    
    run)
        LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH \
        ../Nemo-Test/bin/nemo
        ;;
    
    *)
        echo "Usage: autogen {auto|config|run}"
        ;;
esac

ich würde GNU make empfehlen, wenn ich mit i18n arbeite.

greets

[tE]bachi

 

[juedan]

Hallo razoredge

Was auch noch bestens funktioniert, wenn die strings auf *BSD, *Linux, $SYSTEM ausgegeben werden sollen? Nicht? Och, schade ;-).

Das Lachen wird Dir nun vergehen
IBM und Microsoft (ja ich weiß, rotes Tuch) haben mit diesen Resource-Strings ein System entwickelt, dass ohne Neukomopilierung der Resourcendatei, diese zwischen
OS/1.x, OS/2.x, Windows 3.x und AIX austauschen konnte!
Das hat tatsächlich funktioniert. Heute leider nicht mehr, weil M$ seinen eigenen Weg geht, OS/2 nur noch die liebsten aller Liebhaber kennen und IBM keinen Bock mehr hat.

Schade, war zukunftsweisend!

Viele Grüße

Jürgen

 

[juedan]

Hallo [tE]bach,

danke für die Informationen.
Ich habe erstmal eine nicht-multi-linguale (schönes Wort, gefällt mir) Version des Programms erstellt. Die läuft wenigstens.
Mit Deinen beiden Skripten werde ich mich dann an die multi-linguale Version machen.

Vielen Dank für Deine Hilfe

Jürgen

 

[razoredge]

Hallo razoredge
Das Lachen wird Dir nun vergehen

Nein, siehe unten :-).

IBM und Microsoft (ja ich weiß, rotes Tuch) haben mit diesen Resource-Strings ein System entwickelt, dass ohne Neukomopilierung der Resourcendatei, diese zwischen
OS/1.x, OS/2.x, Windows 3.x und AIX austauschen konnte!
Das hat tatsächlich funktioniert. Heute leider nicht mehr, weil M$ seinen eigenen Weg geht, OS/2 nur noch die liebsten aller Liebhaber kennen und IBM keinen Bock mehr hat.

1.) Kein rotes Tuch, so kleingeistig bin ich nicht ;-).
2.) "Heute leider nicht mehr" trifft es perfekt. Das ist das wesentliche. Damals war auch vieles andere besser (z.B. ordentliche INI-Dateien im Gegensatz zur Registry). Desweiteren lief der Kram nicht mehr auf Solaris, HP-UX, etc.pp., oder?
Gettext liefert hier ja die brauchbare Alternative.
3.) Der Weg, den MS derzeit beschreitet (.NET) ist dieser Geschichte erschreckend aehnlich. Sie arbeiten mit lokalisierbaren Resourcedateien, welche in Programme gelinkt werden und so automatisch die Lokalisierung uebernehmen. Klingt erschreckend nach dem Konzept.

Schade, war zukunftsweisend!

Wie immer bei guten Ideen.

gruss

 

[juedan]

Moin [tE]bachi und razoredge,

das I18n-Problem haben wir nicht in den Griff bekommen können.
Wir sind in unserer Firma einen anderen Weg gegangen, der für uns praktikabler erscheint und auch schneller zum Ziel führt.

Wir packen ähnlich wie Gnome die Strings in ein XML-File und greifen über Indeces auf die Daten zu. Ganz einfach! Für die Übersetzung habe wir ein kleines Tool entwickelt, mit dem der Anwender komfortabel die Zeichenketten übersetzen kann - übrigens auch im Glade-File.

In ca. zwei Monaten werden wir das veröffentlichen.

Viele Grüße

Jürgen

 

[razoredge]

Moin [tE]bachi und razoredge,

das I18n-Problem haben wir nicht in den Griff bekommen können.

Mittlerweile habe ich eine fuer mich praktikable Loesung mit den gnu-* ports aus devel/:

Das autogen.sh script:

#!/bin/sh
# Run this to generate all the initial makefiles, etc.

srcdir=`dirname $0`
test -z "$srcdir" && srcdir=.

cp /usr/local/share/gettext/mkinstalldirs ./
cp /usr/local/share/gettext/config.rpath ./

# dummy to satisfy newer automakes...
touch ABOUT-NLS

PROJECT=projekt_name
libtoolize -c -f
aclocal $ACLOCAL_FLAGS
autoheader
autoconf
automake -c -a $am_opt

Die Programmaufrufe hier beziehen sich auf den jeweiligen gnu-* Port, nicht auf die normalen autotools, die sonst mitinstalliert werden (diese sind ja teilweise umfangreich gepatcht).

configure.ac/in:

...
dnl i18n
ALL_LINGUAS="de po en zh_CN"
AM_GNU_GETTEXT([external])
AM_GNU_GETTEXT_VERSION(0.12.1)
if test "x$LIBINTL" = "x"; then
  LIBINTL="$INTLLIBS"
fi
...

Die Makefiles und Konvertierungen fuer die .po/.mo Dateien sind dann noch manuell geschrieben (~20 Zeilen). Laeuft anscheinend auf jeder Plattform sauber und bisher hat sich niemand beschwert :-).

Wir sind in unserer Firma einen anderen Weg gegangen, der für uns praktikabler erscheint und auch schneller zum Ziel führt.

Wir packen ähnlich wie Gnome die Strings in ein XML-File und greifen über Indeces auf die Daten zu. Ganz einfach! Für die Übersetzung habe wir ein kleines Tool entwickelt, mit dem der Anwender komfortabel die Zeichenketten übersetzen kann - übrigens auch im Glade-File.

In ca. zwei Monaten werden wir das veröffentlichen.

Klingt interessant. Wo wird das dann verfuegbar gemacht?

gruss

 

[juedan]

Hallo razorededge,

Die Makefiles und Konvertierungen fuer die .po/.mo Dateien sind dann noch manuell geschrieben (~20 Zeilen). Laeuft anscheinend auf jeder Plattform sauber und bisher hat sich niemand beschwert :-).

Zitat:
Wir sind in unserer Firma einen anderen Weg gegangen, der für uns praktikabler erscheint und auch schneller zum Ziel führt.

Wir packen ähnlich wie Gnome die Strings in ein XML-File und greifen über Indeces auf die Daten zu. Ganz einfach! Für die Übersetzung habe wir ein kleines Tool entwickelt, mit dem der Anwender komfortabel die Zeichenketten übersetzen kann - übrigens auch im Glade-File.

In ca. zwei Monaten werden wir das veröffentlichen.

Klingt interessant. Wo wird das dann verfuegbar gemacht?

Da ich die treibende Kraft in diesem Projekt war, werde ich es auf meinem Server veröffentlichen.

Der Gag an der Sache ist, daß der gettext-Kram damit absolut nicht mehr notwendig ist. Wir verwenden ein eigenes "gettext", das genauso eingebunden sein wird, wie das originale gettext. Es muß also nur der Code in der main-function um ein paar Zeilen ergänzt bzw. getauscht werden.

Viele Grüße

Jürgen