Datenbanken, Log Files etc. Cross Platform ablegen

Leon0402

@hustbaer hmm aber die Pfade für die installierte Version würden ja bereits von Qt kommne, daher stelle ich mir das mit der Config eher schwierig vor, die wird ja vermutlich eher json oder vergleichbares sein.
Darüber hinaus würden zumindest unter Linux config files ja auch nicht im selben Verzeichnis liegen dürfen. Also wenn man es selbst installiert ist es vlt. okay, aber spätestens wenn das ganze vom Package Manager installiert wird, landen die binaries irgendwo in einem /bin Ordner in dem keine Configs liegen dürfen (sollten).

Was mir vlt. einfallen würde wäre eine Art Wrapper um QStandard Paths zu bauen. Und dann entweder per Makro oder per CMake configure_file die Pfade abhängig von einer CMake Variable Portable dann eben von QStandardPaths zu übernehmen oder relativ ins Verzeichnis zeigen zu lassen.

hustbaer

@Leon0402
Also erstmal meine ich hier kein Config-File in dem Sinn dass darin auch vom Benutzer änderbare Dinge gespeichert würden. Daran wo/wie man diese speichert ändert man nichts, das lässt man einfach so wie es war. Nennen wir das neue Config-File PConfig damit keine Verwirrung entsteht.

Beispiel 1: Die Anwendung schreibt in ein fixes Log-Verzeichnis. Im "installierten" Modus soll das /var/log/foo sein, im "portable" Mode soll es <exe-dir>/log sein. In PConfig macht man dann z.B. einen Eintrag logDir. Für die portable Variante schreibt man logDir ./log rein und für die intallierte Variante schreibt man logDir /var/log/foo rein.

Beispiel 2: Die Anwendung soll in ein vom User-konfigurierbares Log-Verzeichnis schreiben. Der Default soll gleich wie in Beispiel 1 sein. In dem Fall macht man einen defaultLogDir Eintrag in PConfig - entsprechend dem logDir Eintrag aus Beispiel 1. Und verwendet ihn halt nur wenn der Benutzer nichts konfiguriert hat.

die Pfade für die installierte Version würden ja bereits von Qt kommne, daher stelle ich mir das mit der Config eher schwierig vor, die wird ja vermutlich eher json oder vergleichbares sein.

Das Format kannst du bestimmen. Und wenn du die Pfade für die installierte Version von Qt bekommst, dann kannst du z.B. im installierten Fall das Config-File auch einfach weglassen. D.h. die Regel ist dann: wenn PConfig existiert, dann nimm die Pfade von dort (und füttere sie evtl. auch nach Qt rein, wenn das Framework die Pfade auch selbst verwendet). Andernfalls nimm die Pfade die du von Qt bekommst.

Darüber hinaus würden zumindest unter Linux config files ja auch nicht im selben Verzeichnis liegen dürfen. Also wenn man es selbst installiert ist es vlt. okay, aber spätestens wenn das ganze vom Package Manager installiert wird, landen die binaries irgendwo in einem /bin Ordner in dem keine Configs liegen dürfen (sollten).

Trifft das auch auf read-only Files zu? Wie gesagt, das File muss nicht änderbar sein, da sollen nur ein paar Dinge drin stehen die der Benutzer nicht ändern können muss. Alles was der Benutzer ändern kann sollte man wo anders speichern.
Du kannst es auch so machen dass die Defaults bei nicht vorhandenem oder leerem PConfig File passend für die installierte Version sind.

Was mir vlt. einfallen würde wäre eine Art Wrapper um QStandard Paths zu bauen. Und dann entweder per Makro oder per CMake configure_file die Pfade abhängig von einer CMake Variable Portable dann eben von QStandardPaths zu übernehmen oder relativ ins Verzeichnis zeigen zu lassen.

So ein Wrapper könnte schon Sinn machen. Was ich persönlich nicht mag, ist wenn die portable Version und die installierte unterschiedliche gebaut werden müssen. Daher verwende ich da eben lieber solche Config-Files dafür. Und die müssen dann eigentlich "neben" der EXE liegen. Fixer Pfad macht bei "portable" keinen Sinn, und relativer Pfad ausser . macht mMn. auch wenig Sinn.

Wenn es dich nicht stört dass du zwei verschiedene Binaries brauchst, ist das aber natürlich auch eine Möglichkeit.

hustbaer

Man kann das ganze auch etwas abändern: Vorausgesetzt es gibt schon ein Config-File, kann man dieses erstmal "neben" dem EXE File suchen. Wenn man es dort findet, nimmt man es von dort. Wenn nicht, geht man davon aus dass man "installiert" ist, und sucht es dort wo es in der "installierten" Variante liegt.

So braucht man nur ein Config-File, nicht eins für "fixe" und eins für änderbare Einstellungen.

Wichtig ist hauptsächlich dass man relative Pfade im Config-File erlaubt, und diese relativ zum Verzeichnis des Config-Files interpretiert.

Was ich beim "Konfigurieren duch Weglassen des Files" aber doof finde, ist dass man dann eine unsichtbare Abhängigkeit darauf hat dass das File nicht existieren darf. Daher finde ich es besser das File mit zu installieren wenn möglich.

Leon0402

@hustbaer sagte in Datenbanken, Log Files etc. Cross Platform ablegen:

@Leon0402
Also erstmal meine ich hier kein Config-File in dem Sinn dass darin auch vom Benutzer änderbare Dinge gespeichert würden. Daran wo/wie man diese speichert ändert man nichts, das lässt man einfach so wie es war. Nennen wir das neue Config-File PConfig damit keine Verwirrung entsteht.

Okay, das hatte ich vermutet

@hustbaer sagte in Datenbanken, Log Files etc. Cross Platform ablegen:

Trifft das auch auf read-only Files zu? Wie gesagt, das File muss nicht änderbar sein, da sollen nur ein paar Dinge drin stehen die der Benutzer nicht ändern können muss. Alles was der Benutzer ändern kann sollte man wo anders speichern.

Soweit ich weiß, habe es jedenfalls noch nie gesehen. Aber das muss nichts unbedingt heißen.

Ich denke aber der Hauptgrund gegen eine "Install Config File" wäre aber auch, dass ich QT verwenden will. Klar könnte man dann auch ne Config File für Windows, Linux, Mac Os etc. haben, aber leichter wäre es natürlich über die Abstraktion. Dann machen sich andere Gedanken, was jetzt und potentiell in Zukunft die richtigen Pfade sind.

@hustbaer sagte in Datenbanken, Log Files etc. Cross Platform ablegen:

Wenn es dich nicht stört dass du zwei verschiedene Binaries brauchst, ist das aber natürlich auch eine Möglichkeit.

Ich bin mir nicht sicher Ich glaube erstmal an sich nicht. Die Build Zeiten kann man ja beschleunigen, indem man die Config in ne Lib abwandelt. Das mache ich bereits so für die Versionsnummer. Also sprich eine eigene Library AppVersion & AppConfig. Ändert man die Config, muss man quasi nix neu kompilieren.

@hustbaer sagte in Datenbanken, Log Files etc. Cross Platform ablegen:

Man kann das ganze auch etwas abändern: Vorausgesetzt es gibt schon ein Config-File, kann man dieses erstmal "neben" dem EXE File suchen. Wenn man es dort findet, nimmt man es von dort. Wenn nicht, geht man davon aus dass man "installiert" ist, und sucht es dort wo es in der "installierten" Variante liegt.

Wäre auch keine schlechte Möglichkeit. Damit würde man den Nachteil mit dem Neubuilden auch nochmal vermeiden.

Gibt es eigentlichen einen Standard, was die portable Version angeht? Daher wie sowas auszusehen hat. Ich könnte natürlich einmal meinen build Ordner zippen und dann könnte man das wohl mit Fantasie als portable bezeichnen Schätze mal üblich ist aber eher, dass man nur einen Ordner mit nur binary und libs hat, oder?

hustbaer

@Leon0402
Im Archiv für eine portable Version sind normalerweise nur die Files drin die nötig sind um das Programm zu verwenden + ggf. Dokumentation in Form von plain Text, HTML oder Markdown files. Wenn du willst kannst du gerne noch das .pdb/.dbg File dazupacken. Mehr ist eigentlich nicht üblich.

Anmerkung dazu: ein File mit Infos über verwendete Third-Party Libraries kann je nach Lizenz dieser nötig sein, wenn es sonst nirgends in der Software ersichtlich ist (About Dialog o.ä.). Und wenn deine Software unter GPL steht sollte natürlich noch die Info enthalten sein wo man sich den Source Code besorgen kann. Beides gilt natürlich auch für installierte Programme.

Schlangenmensch

@Leon0402 Sorry für die späte Antwort, ich habe die letzte Woche nur über's Smartphone mitgelesen und da @hustbaer eigentlich alles zu dem Thema gesagt hat, habe ich mir das frickelige Tippen gespart.

Wir machen es noch etwas anders. Unsere Software ist momentan Windows only und da haben wir eine kleine, nicht so schöne Abhängigkeit drinnen. Das Setup für die normale installierte Version schreibt einen Eintrag in die Registry mit einem Pfad zur Exe. Wenn der Eintrag existiert und mit dem Pfad zur ausgeführten Datei übereinstimmt ist es eine normale installierte Version, ansonsten die Portable.

Bei Debian Distributionen könnte man vlt gucken, ob man via dpkg -L oder dpkg-query das auch über die Pfade erledigen kann.
Aber das ist halt frickelig, da das für alle Distributionen irgendwie anders ist, daher wäre es für Crossplatform wahrscheinlich am einfachsten, wenn das Setup eine Configdatei mit der entsprechenden Information anlegt.

Wir erstellen unsere Setups mit Innosetup [https://jrsoftware.org/isinfo.php] aber das ist halt Windows only. Ich habe mich noch nicht damit auseinander gesetzt, wie man das am geschicktesten als Paket für Linuxdistributionen anbieten würde.

Nerdy22

Hallo,
da es keine gute Stimmen für die Linux TTS-Engines gibt und jährlich Lizenzkosten erhebt, suche ich nach einer Möglichkeit, wie ich die MS TTS api in Linux c++ Programmen einbinden kann. Entweder über wine oder via Virtualbox etc.

Kennt sich damit jemand aus?

VG

hustbaer

@Nerdy22
Was ist eine TTS-Engine? Und inwiefern hat das etwas mit diesem Thread zu tun?

text-to-speech engine.
mit dem thread hat es allerdings immernoch nichts zutun.

hustbaer

Ah. In dem Fall: klar kann man das irgendwie machen. Also speziell wenn VirtualBox eine Option ist muss das gehen. Im Worst-Case muss man sich z.B. ein Netzwerk-Service/Web-Service basteln das den Text entgegennimmt, in die TTS Engine reinwirft, und die produzierte Waveform über's Netz zurückschickt. Und das lässt man dann auf Wine laufen. Bzw. wenn es mit Wine nicht funktioniert, dann funktioniert es mit an Sicherheit grenzender Wahrscheinlichkeit auf VirtualBox, KVM oder was man sonst so als Hypervisor rumliegen hat.