Pfad um aus der GUI auf CLI-Programme in ./Contents/MacOS/ zuzugreifen? - Mkvtoolnix

[Harry3]

Hallo,

versuche gerade die Mac-App für die aktuelle Mkvtoolnix-Version zu erstellen, habe aber das Problem mit dem Pfad zu mkvmerge (CLI-Programm das sich in ./Mktvoolnix.app/Contents/MacOS/ befindet). Google-Suche war irgendwie nicht so hilfreich und durch ausprobieren habe ich herausgefunden dass mkvmerge im Ordner ./Mkvtoolnix.app/Contents/MacOS/ durch eben diese Pfadangabe (./Mkvtoolnix.app/Contents/MacOS/mkvmerge) gefunden wird. Das Problem ist aber dass eine Umbenennung der App das Problem schaffen würde dass mkvmerge nicht mehr gefunden wird.

Gibt es eine Möglichkeit den Pfad irgendwie anzugeben ohne dass der App-Name explizit angegeben wird so dass auch eine Umbenennung kein Problem wäre?

All die Tools (mkvmerge, mkvinfo, ...) werden mit aktuellem clang ohne irgendwelche Patches mit neuestem Xcode 5.1.1 statisch compiliert (6.8, 6.9 und 6.9.1 bisher compiliert), die Mkvtoolnix-GUI läuft inzwischen auch recht gut (es funktioniert auch Drag & Drop), es gibt aber noch das Problem (so lange man die App nicht umbenennt kein Problem aber dadurch nicht wirklich Mac-like) mit dem Pfad.

 

[pmau]

Zuerst mal:

Ich habe mir die App nicht angeschaut. Stelle mir aber vor dass es sich um eine OpenSource App als Frontend für mkvtools handelt.

Normalerweise:

Derjenige der die App programmiert, fragt normalerweise nach dem Ort seines Programbundles und ruft dan "relativ" dazu alle Tools auf, die er mit in die App legt.
Dadurch braucht man den Pfad der App garnicht zu kennen.

Da es aber offensichtlich nicht der Fall ist, würde ich die Kommandozeilen Tools nach /usr/local kopieren, dass von OSX nicht verwendet wird.
Also sollte derjenige der die App schreibt entweder die erste Variante benutzen oder einen Installer schreiben der die Tools an eine feste Stelle kopiert.

(Was allerdings nicht schön ist)

Ich hab' mir jetzt die App nicht angeschaut, kann mir aber nicht vorstellen, dass das der Sinn der Sache ist, wenn man sie selber baut.

 

[Harry3]

Der Autor von mkvtoolnix (und mkvmerge, mkvinfo, ...) ist ein sehr netter und hilfsbereiter Mensch der allerdings nur Linux und Windows unterstützt. Da aber wxwidgets und boost genützt werden, kann man eben die GUI auch auf dem Mac zum laufen kriegen. Da ich weder auf Mac Ports noch Brew eine lauffähige Version gefunden habe, habe ich es eben mit Hilfe des Autors versucht die ganzen Programme auch auf dem Mac mit aktuellem Xcode zu compilieren. Die mit clang compilierten CLI-Programme (mkvmerge, mkvinfo, ...) funktionieren bisher ohne Probleme und die Anleitung wird es in absehbarer Zeit geben.

Ich kann jetzt ein Application Bundle erstellen das die GUI (mmg) nutzt, habe aber u.a. das Problem dass mkvmerge nur durch die Angabe des oben genannten Pfades gefunden wird und wollte daher fragen ob es da nicht noch eine andere Möglichkeit gibt auf CLI-Programme im ./Contents/MacOS-Ordner zuzugreifen.

Derjenige der die App programmiert, fragt normalerweise nach dem Ort seines Programbundles und ruft dan "relativ" dazu alle Tools auf, die er mit in die App legt.
Dadurch braucht man den Pfad der App garnicht zu kennen.

Richtig. Den Pfad der App brauche ich ja jetzt schon nicht, aber so wie es aussieht den Namen der App und das würde mich wundern wenn der wirklich nötig wäre denn eine Umbenennung hätte zur Folge dass eben die Programme in dem Unterordner nicht mehr gefunden würden.

 

[pmau]

OK

Du hast also die Kommandozeilen Tools selber in die App gelegt.
Die App hat vermutlich irgendwo die Pfade zu den Programmen. In Preferences oder wie auch immer.

Der Trick ist, die "mmp" App so zu ändern, dass sie beim Start die Programme selber findet.

Beispiel:

Die App ist in "/Applications/mmg.app"

https://developer.apple.com/library....html#//apple_ref/doc/uid/10000123i-CH104-SW6

NSString *codePath = [NSBundle mainBundle];  // Ergibt "/Applications/mmg.app/Contents/MacOS"
NSString *mkvToolTest = [codePath stringByAppendingPathComponent:@"mkvwhatever"]; // Ergibt "/Applications/mmg.app/Contents/MacOS/mkvwhatever"

Dann kann man die App verschieben wohin man will.

EDIT: Alles einfach nur getippt. Aber so geht das ungefähr.

 

[Gondomir]

In main(int argc, char *argv[]) ist argv[0] der Programmname.

 

[Harry3]

@pmau

Danke, aber die ganzen Mac-Libraries können nicht genutzt werden. Denke aber dass das Problem in einer der nächsten Version gelöst sein wird und es in nicht zu ferner Zukunft eine automatisch compilierende Mac-Version geben wird.

In main(int argc, char *argv[]) ist argv[0] der Programmname.

Aha.

 

[Gondomir]

Löst das nicht das Problem: "Das Problem ist aber dass eine Umbenennung der App das Problem schaffen würde dass mkvmerge nicht mehr gefunden wird."?
Es ist natürlich der aktuelle Programmname, wie es aufgerufen wird. Wenn du das Executable "max" nennst, steht da auch max drin.
Oder habe ich das Problem falsch verstanden?

 

[pmau]

Ich habe es mir gerade mal angeschaut. wxWidgets also ... Ich dachte halt, jemand baut eine Mac App ...

 

[Gondomir]

Ich habs grad probiert: Öffnet man die App mit Doppelklick dann wird der ganze Pfad ausgeben, z.B.:
/Users/ganter/Xcode-Projekte/Flocati/DerivedData/Flocati/Build/Products/Debug/Flocati.app/Contents/MacOS/Flocati

Ist wxWidgets nicht in C?

 

[Harry3]

Ich habe es mir gerade mal angeschaut. wxWidgets also ... Ich dachte halt, jemand baut eine Mac App ...

Vermutlich hatte ich mich widersprüchlich ausgedrückt. Die App sieht inzwischen ziemlich Mac-like aus. Man kann sie verschieben, umbenennen, Drag & Drop funktioniert.

Es ist natürlich der aktuelle Programmname, wie es aufgerufen wird. Wenn du das Executable "max" nennst, steht da auch max drin.
Oder habe ich das Problem falsch verstanden?

Vermutlich denn das ausgeführte Programm heißt mmg. Dieses Programm muss aber CLI-Programme aufrufen die sich im Application Bundle im Ordner MacOS befinden. Den Pfad kann man relativ zum Application-Bundle (als ./Application-Bundle-Name/Contents/MacOS) angeben (was aber das Problem hat dass bei einer Änderung des Namens das CLI-Programm nicht mehr gefunden wird) oder aber man nutzt Mac-Funktionen wie pmau geschrieben hat oder bei Entwicklung für mehrere Systeme (Linux/Windows/OS X) nutzt man Libraries wie boost. Der Aufwand für mehrere Systeme zu programmieren ist halt nicht unerheblich und da wollte ich halt bei der Mac-Version helfen.