Die beste Möglichkeit, ein benutzerdefiniertes Kakaorahmenwerk zu installieren

Question

Ich habe ein benutzerdefiniertes Framework, das nach dem Ratgeber in Apples Framework Programming Guide >>Installing your framework in/Library/Frameworks installiert wird. Ich tue dies, indem ein Skript ausführen Hinzufügen bauen Phase mit dem folgenden Skript:

cp -R build/Debug/MyFramework.framework /Library/Frameworks 

In meinen Projekten habe ich dann verknüpfen gegen/Library/Frameworks/MyFramework und importieren Sie es in meinen Klassen wie folgt:

#import <MyFramework/MyFramework.h> 

das funktioniert sehr gut, außer dass ich die folgende Meldung in meinem Debugger Konsole immer sehen:

Laden Programm in Debugger ... sharedlibrary gelten lasteten alle Regeln Warnung: Symbole für "/Users/elisevanlooij/Library/Frameworks/MyFramework.framework/Versions/A/MyFramework" (Datei nicht gefunden) konnten nicht gelesen werden. Warnung: Kann Symbole aus "MyFramework" nicht lesen (noch nicht im Speicher zugeordnet). Programm geladen.

Offenbar der Compiler sucht zuerst in/Users/elisevanlooij/Library/Frameworks können MyFramework nicht finden, sieht dann in/Library/Frameworks, MyFramework findet und weiter auf fröhliche Art und Weise. Bisher war dies eher ein Ärgernis als ein echtes Problem, aber wenn man Komponententests durchführt, stoppt gdb bei der (Datei nicht gefunden) und weigert sich weiterzumachen. Ich habe das Problem durch Hinzufügen einer zusätzlichen Zeile in den Run-Script Phase

cp -R build/Debug/MyFramework.framework ~/Library/Frameworks 

gelöst, aber es fühlt sich an wie sello-Taping etwas, das nicht in erster Linie gebrochen werden sollte. Wie kann ich das beheben?

Answer 1

In den letzten Monaten habe ich viel mehr über Frameworks gelernt, also schreibe ich diese Antwort um. Bitte beachten Sie, dass ich über ein Framework als Teil des Entwicklungsworkflows installieren. Der bevorzugte Ort für die Installation eines öffentlichen Frameworks (dh eines Frameworks, das von mehr als einer Ihrer Apps oder Bundles verwendet wird) ist/Library/Frameworks [link text], da "Frameworks an diesem Speicherort automatisch von der. Entdeckt werden Compiler zum Zeitpunkt der Kompilierung und der dynamische Linker zur Laufzeit. "[Framework Programming Guide]. Die eleganteste Methode hierfür ist im Abschnitt Bereitstellung der Build-Einstellungen.

Während Sie an Ihrem Framework arbeiten, gibt es Zeiten, in denen Sie das Framework aktualisieren möchten, wenn Sie einen Build erstellen, und Zeiten, wenn Sie dies nicht tun. Aus diesem Grund ändere ich die Bereitstellungseinstellungen nur in der Release-Konfiguration. So:

1. Doppelklicken Sie auf das Framework-Ziel, um das Fenster mit den Zielinformationen zu öffnen und zur Registerkarte Erstellen zu wechseln.
2. Wählen Sie Freigabe in der Konfigurationsauswahlbox. Abschnitt
3. Blättern Sie zum Deployment und geben Sie die folgenden Werte:

Deployment Location = YES (klicken Sie das Kontrollkästchen)

Einbau Bauen Produkte Standort =/

Installationsverzeichnis =/Bibliothek/Frameworks

Die Installation Build Products Location dient als Wurzel der Installation. Der Standardwert ist ein Verzeichnis/tmp: Wenn Sie es nicht zum Systemstamm ändern, sehen Sie Ihr installiertes Framework nie, da es sich in/tmp versteckt.

Jetzt können Sie an Ihrem Framework arbeiten, wie Sie möchten, in der Debug-Konfiguration, ohne Ihre anderen Projekte zu stören und wenn Sie bereit sind zu veröffentlichen, alles, was Sie tun müssen, ist auf Release wechseln und eine Build.

Xcode 4 Warnung Seit dem Wechsel zu Xcode 4 habe ich eine Reihe von Problemen mit meinem benutzerdefinierten Framework erlebt. Meistens verknüpfen sie Warnungen in GDB, die die Nützlichkeit des Frameworks nicht beeinträchtigen, außer wenn der integrierte Komponententest ausgeführt wird. Ich habe vor einer Woche ein Ticket für den technischen Support bei Apple eingereicht, und sie prüfen es immer noch. Wenn ich eine funktionierende Lösung bekomme, werde ich diese Antwort aktualisieren, da sich die Frage als ziemlich populär erwiesen hat (1 kViews and counting).

Answer 2

Natürlich, wenn Sie Ihr Framework vertreiben, sollte es in/Library/Frameworks installiert werden; Es erscheint mir jedoch merkwürdig, dass Sie das mit den Test/Debug-Versionen Ihres Frameworks machen.

Mein erster Instinkt wäre es, Testversionen unter ~/Library zu installieren, da dies die Einrichtung Ihrer Test- und Debugumgebung viel einfacher macht. Wenn möglich, würde ich erwarten, dass sich das Debug/Test-Framework in der Build-Struktur der getesteten Version befindet. In diesem Fall wird es zu Testzwecken als Private Framework installiert. Das würde Ihr Leben viel einfacher machen, wenn es darum geht, mit mehreren Versionen Ihres Frameworks zu arbeiten.

Letztendlich spielt es keine Rolle, wo sich das Framework befindet, solange Ihre Anwendung oder Testsuite die richtige Version lädt. Wählen Sie den Speicherort, der das Testen/Debuggen/Entwickeln am einfachsten macht.

Answer 3

Es gibt nicht viel Grund, ein Framework in Library/Frameworks zu setzen, und es ist eine Menge Arbeit: Sie müssen es entweder für den Benutzer in einem Installer-Paket tun, was eine enorme Hektik zum Erstellen und Pflegen ist. oder haben Sie einen Installationscode in Ihrer App (der nur in ~/L/F installiert werden kann, sofern Sie nicht die Zeit und den Aufwand für die Installation Ihrer App in/L/F mit Root-Rechten aufwenden).

Viel häufiger ist what Apple calls a “private framework”. Sie bündeln dies in Ihrem Anwendungspaket.

Sogar Frameworks, die für die allgemeine Verwendung durch beliebige Anwendungen gedacht sind (zB Sparkle, Growl), sind in der Praxis als private Frameworks konzipiert, einfach weil die "richtige" Art der Installation einer einzigen Kopie des Frameworks in der Library ist/Frameworks ist so ein Ärger.

Answer 4

Der herkömmliche Weg dazu besteht darin, dass Ihr Framework-Projekt und seine Clients ein gemeinsames Build-Verzeichnis verwenden. Xcode sucht nach Framework-Headern und verlinkt gegen Framework-Binärdateien im Build-Ordner zuerst, vor jedem anderen Ort. Ein App-Projekt, das kompiliert und mit dem Header verknüpft wird, wird also das zuletzt erstellte und nicht das, was installiert ist, abholen.

Sie können dann den cp -r entfernen und stattdessen die Build-Einstellung Install Location verwenden, um Ihr Build-Produkt am endgültigen Speicherort zu platzieren, indem Sie xcodebuild install DSTROOT =/in der Befehlszeile verwenden. Aber Sie müssen dies nur tun, wenn Sie fertig sind, nicht jedes Mal, wenn Sie das Framework neu erstellen.