Auf inf.plist-Keys in Run-Script-Phase zugreifen

  • Auf inf.plist-Keys in Run-Script-Phase zugreifen

    Hallo!

    Gibt es eigentlich eine Möglichkeit, während des Build-Prozesses, speziell in einer Run-Script-Phase, auf die Key-Informationen der info.plist zuzugreifen?

    Derzeit habe ich das so gelöst, dass ich z. B. Versions-Informationen doppelt pflege, nämlich einmal in der info.plist und einmal als eigene Target-Build-Variablen. Auf letztere kann ich sehr simpel zugreifen - nur auf erstere nicht. Ich möchte aber nicht gern dopplet pflegen.

    Gibt es da was?

  • RE: Auf inf.plist-Keys in Run-Script-Phase zugreifen

    Ah! Das sieht sehr gut aus.

    Kannst Du mir bitte noch einen Tipp geben, denn ich bin leider überhaupt kein shell-script-Crack: Wie würde ich nun eine Variable auslesen, (vermutlich) in einer eigenen, lokalen Variable speichern und beim Aufruf eines anderen cmd-line-Tools verwenden?

    Irgendwie à la:

    Quellcode

    1. $VERSION = plistbuddy Print :CFBundleVersion

    oder so ...? Wie gesagt, meine shell-scripting-Erfahrung endet leider mit dem Aufruf von Kommandozeilen-Tools.

  • braucht man gar nicht!

    man kann das bereits vorhandene "defaults" verwenden um plists zu lesen und zu schreiben.

    wenn zb der pfad zu deiner datei so lautet: /Pfad/zur/Datei/Info.plist

    dann rufst du das tool so auf:

    defaults read /Pfad/zur/Datei/Info

    oder so:

    defaults read /Pfad/zur/Datei/Info DEIN_KEY

    man beachte dass die endung ".plist" weggelassen wird!

    das ganze klappt auch schreibend!

    GG

  • Original von gritsch
    braucht man gar nicht!

    man kann das bereits vorhandene "defaults" verwenden um plists zu lesen und zu schreiben.

    wenn zb der pfad zu deiner datei so lautet: /Pfad/zur/Datei/Info.plist

    dann rufst du das tool so auf:

    defaults read /Pfad/zur/Datei/Info

    oder so:

    defaults read /Pfad/zur/Datei/Info DEIN_KEY

    man beachte dass die endung ".plist" weggelassen wird!

    das ganze klappt auch schreibend!

    GG

    PlistBuddy ist auch "bereits vorhanden". Und kann auch schreiben.

    Dass der uralte defaults-Befehl jetzt auch einen Dateipfad akzeptiert war mir neu.

    Was hat sich Apple da mal wieder gedacht? Zwei Tools die beide das gleiche können...

    Welches ist nun "besser"?

    -- hns

  • Original von hns
    Original von gritsch
    braucht man gar nicht!

    man kann das bereits vorhandene "defaults" verwenden um plists zu lesen und zu schreiben.

    wenn zb der pfad zu deiner datei so lautet: /Pfad/zur/Datei/Info.plist

    dann rufst du das tool so auf:

    defaults read /Pfad/zur/Datei/Info

    oder so:

    defaults read /Pfad/zur/Datei/Info DEIN_KEY

    man beachte dass die endung ".plist" weggelassen wird!

    das ganze klappt auch schreibend!

    GG

    PlistBuddy ist auch "bereits vorhanden". Und kann auch schreiben.

    Dass der uralte defaults-Befehl jetzt auch einen Dateipfad akzeptiert war mir neu.

    Was hat sich Apple da mal wieder gedacht? Zwei Tools die beide das gleiche können...

    Welches ist nun "besser"?

    -- hns


    ich weis net welches besser ist - ich verwende "defaults" halt sonst auch öfters also warum in di ferne schweifen ;)

  • Original von macmoonshine
    In diesem Fall natürlich:

    Quellcode

    1. VERSION = `defaults read <PFAD> CFBundleVersion`
    ;)

    EDIT: Wichtig sind die Akzente und bei einer Zuweisung im Shellskript darf kein Dollar vor der Variablen auf der linken Seite stehen.

    Etwas modernere Shell-Syntax (die ggf. auch mit Schachtelungen zurechtkommt):

    Quellcode

    1. VERSION = $(defaults read $PFAD/Info CFBundleVersion)

    -- hns

  • Original von gritsch
    ich weis net welches besser ist - ich verwende "defaults" halt sonst auch öfters also warum in di ferne schweifen ;)

    Aha, auf meinem System ist der PlistBuddy gar nicht in $PATH (sondern in /usr/libexec). Dann ist defaults die zuverlässigere (und wirklich nähere) Methode!

    -- hns

  • Etwas verspätet, aber: Ich habe es nun so wie vorgeschlagen (defaults ...) umgesetzt.

    Nun komme ich zu einer weiteren Frage: Für den Copyright-String setze ich in den user settings des Build Targets die Variable START_YEAR. In der Run-Script-Phase funktioniert das Auslesen, logisch.

    Aber gibt es eine Möglichkeit, diesen Wert zurück in meinen Code zu bekommen, denn dort benötige ich diese Info ebenfalls und würde ungern zweimal den Wert pflegen.