ubuntuusers.de

Hallo zusammen!
Ich möchte, dass eine Binary im aktuellen Verzeichnis erstellt wird und danach (per make install) erst in sein Verzeichnis /usr/share... kopiert (oder verschoben) wird. Hierzu könnte ich die Makefile anpassen, jedoch wäre es günstiger, wenn qmake das Makefile gleich so erstellt, dass die Regel 'install:' das Binary kopiert (od. verschiebt). Das Gleiche gilt für Verknüpfungen. Was muss ich tun, damit beim Erstellen der Makefile in der Regel 'install:' eine Verknüpfung einer noch nicht vorhandenen Datei, nämlich der Binary, erzeugt wird (die Binary existiert erst nachdem 'make' ausgeführt wurde)?
In der .pro Datei habe ich es schon mit 'BIN.file += ProgrammName', 'BIN.path += /usr/share/Programm/ProgrammName' und 'INSTALLS += BIN' versucht, aber da die Binary noch nicht existiert wird dies nicht in der Makefile berücksichtigt (dazu müsste man erst make ausführen und dazu muss das Makefile bereits existieren)... Für die Verknüpfung habe ich noch keine Idee...

Gruß Hakaishi

halb gelöst!

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

TARGET = qt-shutdown-p
TEMPLATE = app
DEPENDPATH += . locale src
INCLUDEPATH += . src

# Input
HEADERS += src/gui.h
SOURCES += src/gui.cpp src/main.cpp

# install
target.path = /usr/share/qt-shutdown-p
translation.files = locale/de.ts
translation.path = /usr/share/qt-shutdown-p
icon.files = pixmap/red_glasses.png
icon.path = /usr/share/pixmaps
...
...
man.files = man/qt-shutdown-p.1.gz
man.path = /usr/share/man/man1

INSTALLS += target translation icon man

if(exists(/usr/share/qt-shutdown-p/qt-shutdown-p)){
system(ln -s /usr/share/qt-shutdown-p/qt-shutdown-p /usr/bin/qt-shutdown-p)}
else{error(no binary to link to)}

aber wie schaffe ich es, dass der link-Befehl in die Makefile kommt??? - Er soll ja erst bei 'make install' ausgeführt werden.
Eine Möglichkeit muss es geben! Ich glaube man kann das irgendwie definieren, aber wie???

Gruß
Hakaishi

Man installiert ausführbare Binärdateien nicht nach /usr/share/. Dieses Verzeichnis ist für architekturunabhängige Daten vorgesehen, es ist daher durchaus legitim, dass /usr/share/ mit "noexec" eingebunden ist, und somit den Start von Programmen gar nicht erlaubt. Programme gehören nach /usr/bin/ oder /usr/local/bin/ (je nach Installationsart).

Nach /usr/share/pixmaps/ gehört eigentlich auch nur das Symbol der Anwendung (für Menüeinträge und dergleichen). Anwendungsspezifische Bilddateien gehören in /usr/share/${name}/, (wobei ${name} der Name der Anwendung ist). Lokalisierungsdaten wiederum gehört nach /usr/share/locale/${lang}/${name}.ts (wobei ${lang} das ISO-Kürzel der Sprache ist, z.B. de).

Üblicherweise bestimmt man all diese Pfade ausgehend von dem benutzerdefinierten Installationspräfix (das meist entweder /usr/ oder /usr/local/ lautet). Dieses Präfix wird in die Anwendung einkompiliert, so dass sie zur Laufzeit ihre Dateien auch findet.

Da Deine Anwendung allerdings nicht übermäßig groß ist, wäre es wohl wesentlich einfacher, das Ressourcen-Feature von Qt zu nutzen, um die benötigten Daten und die Lokalisierungsdateien einfach in die Anwendung einzukompilieren. Dann musst Du nur Symbol, Menüeintrag und Binary installieren.

@Lunar:
Das Verknüpfungsproblem habe ich jetzt Programm-intern gelöst, daher liegt das Binary von nun an in /usr/bin/. Es gibt nur eine Bilddatei, und das ist das Programm-Symbol, welches sowieso ab dem nächsten Update in /usr/share/pixmaps/ liegt.
Die Sprachdatei, welches das Programm benutzt ist übrigens .qm, nicht .ts. Die .ts ist nur die Datei aus der die .qm erstellt wird.
Wenn die Sprachdatei nun, wie du geschrieben hast, nach /usr/share/locale/${lang}/${name}.qm soll, dann sag mir doch bitte, wie ich das in der .pro anwende. Da andere User eventuell eine andere Sprache benutzen, kann ich wohl kaum einfach /usr/share/locale/de/blabla.qm benutzen (das wäre vielleicht ein Schreibaufwand, wenn ich mehr als 10 Sprachdateien hätte...). Ich habe nachgesehen, ob es eine entsprechende qmake Funktion oder qmake Variable gibt, jedoch nichts gefunden... Wenn du übrigens mal in das Verzeichnis /usr/share/locale/de/ hinein siehst, wirst du feststellen, das nur wenige Programme und dann nur mit der Endung .mo gespeichert sind. Die Sprachdateien für den QT Creator sind übrigens hier: /usr/share/qtcreator/translations

Gruß
Hakaishi

Die Pfad der Übersetzungsdateien allerdings war mein Fehler, richtig lautet er /usr/share/locale/${lang}/LC_MESSAGES/. Der Designer mag seine Sprachdateien an anderer Stelle ablegen, üblich ist das trotzdem nicht. Zumindest /usr/share/locale/ wird im FHS erwähnt.

Wie Du das umsetzt: Keine Ahnung, ich kenne mich mit qmake nicht aus. Allerdings wird dieses Buildsystem wohl irgendeine Art von Kontrollstruktur bieten, dann ist das eigentlich nicht weiter schwer. Schließlich kannst Du dann einfach über die *.qm-Dateien iterieren, die Sprache aus dem Datennamen extrahieren und anschließend in das passende Verzeichnis speichern.

Edit: Ich persönlich würde Dir aber wirklich zur Verwendung von Ressourcen raten. Zum einen verringert es den Installationsaufwand, zum anderen kann der Nutzer so eigentlich auch auf die Installation verzichten. Es würde dann reichen, einfach die Binärdatei an einen Ort in $PATH zu kopieren.

Lunar schrieb:

Die Pfad der Übersetzungsdateien allerdings war mein Fehler, richtig lautet er /usr/share/locale/${lang}/LC_MESSAGES/. Der Designer mag seine Sprachdateien an anderer Stelle ablegen, üblich ist das trotzdem nicht. Zumindest /usr/share/locale/ wird im FHS erwähnt.

Auf der Seite steht allerdings auch "nls Message catalogs for Native language support (optional)", jedoch existieren /usr/share/nls und /usr/share/games überhaupt nicht... (okay, sind ja auch optional). Wenn du mal ls /usr/share/locale/de/LC_MESSAGES/*.qm eintippst, wirst du nichts finden...
Bei mir gibt z.B. ls /usr/share/qt4/translations/ Sprachdateien für den QT 4 Assistant, den QT 4 Designer, den QT 4 Linguist.... aus

Gruß
Hakaishi

@hakaishi: Wie viele Qt4-Programme, die nicht Teil von KDE sind, nutzt man denn auch?

Aber Du hast offenbar recht, es scheint bei solchen in der Tat üblich zu sein, Übersetzungen an einem anderen Ort abzulegen. smplayer und VirtualBox jedenfalls legen ihre Übersetzungsdateien auch unter /usr/share/${name}/ ab.