Swift-Framework verwenden

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Um nochmal auf das ursprüngliche Problem zurückzukommen: Inzwischen geht es. Warum es jetzt geht? Keine Ahnung. Ich habe im Zielprojekt die derived-data gelöscht und Xcode neu gestartet. Also eher ein kleiner Bug in Xcode.

    Dazu noch am Rande: So ein Swift-Bundle wird durch die inkludierten Libs ganz schön fett: 14MB zu 140KB eines funktional vergleichbaren Objective-C Bundles. Wahrscheinlich ist das der Grund warum das iPhone 7 mit mindestens 32GB Flash daherkommt. Irgendwo müssen die ganzen Swift-Apps ja Platz finden :D

  • torquato schrieb:

    gandhi schrieb:

    Und, BTW, kann man eigentlich in Swift eine static-library bauen?
    Klare Antwort: Nein.

    Zumindest z.Zt. noch nicht.

    Das hat folgenden Grund: Die ABI ist noch nicht festgelegt.
    Das bezweifle ich, denn das ABI-Problem betrifft dynamische Libraries/Frameworks ja genauso.

    torquato schrieb:

    Eine stabile ABI ist auf Swift 4 verschoben worden, kommt also frühestens im Laufe 2017. Ohne stabile ABI macht es keinen Sinn, Swift-Bibliotheken im System zu verankern. Um Swift trotzdem frühstmöglich 'funktionsfähig' zu machen, greift Apple zu einem Trick und kompiliert die stdlib in die Excecutables hinein. Deshalb sind Swift Apps auch ohne Systemupdate auf Rechnern lauffähig.
    Nein, Apple kopiert diverse zum Executable ABI-kompatible, dynamische Swift-System-Libraries in das App-Bundle.

    torquato schrieb:

    Bei einer static-lib kommt es dadurch zu Problemen. 1.) die Lib und der restliche Code können unterschiedliche ABIs haben
    Wie bereits gesagt, das selbe Problem kannst du mit dynamischen auch Libraries haben.

    torquato schrieb:

    2.) es gibt 'duplicate symbols'.
    Warum?

  • Michael schrieb:

    torquato schrieb:

    gandhi schrieb:

    Und, BTW, kann man eigentlich in Swift eine static-library bauen?
    Klare Antwort: Nein.
    Zumindest z.Zt. noch nicht.

    Das hat folgenden Grund: Die ABI ist noch nicht festgelegt.
    Das bezweifle ich, denn das ABI-Problem betrifft dynamische Libraries/Frameworks ja genauso.

    U.A. aus diesem Grund verwendet Apple bisher auch noch keine in Swift geschriebene systemweite Libraries/ Frameworks. Mit dem nächsten Update (Sprache oder System) sind die nicht mehr kompatibel.

    Michael schrieb:

    torquato schrieb:

    Eine stabile ABI ist auf Swift 4 verschoben worden, kommt also frühestens im Laufe 2017. Ohne stabile ABI macht es keinen Sinn, Swift-Bibliotheken im System zu verankern. Um Swift trotzdem frühstmöglich 'funktionsfähig' zu machen, greift Apple zu einem Trick und kompiliert die stdlib in die Excecutables hinein. Deshalb sind Swift Apps auch ohne Systemupdate auf Rechnern lauffähig.
    Nein, Apple kopiert diverse zum Executable ABI-kompatible, dynamische Swift-System-Libraries in das App-Bundle.

    Nein. Das funktioniert so auch mit CLI-tools. Die haben aber kein Bundle. Da kann nichts in ein Bundle reinkopiert werden. Es gibt keine libCoreSwift.dylib oder dergleichen unter Apple-Devices. Alles, was ein CLI-tool aus der Swift-stdlib braucht, wird z.Zt. tatsächlich ins Executable reinkompiliert/-kopiert.

    Das, was Du da im App-Bundle siehst, sind m.W. Obj-C Cocoa Wrapper Stubs... Aber in dem Detail kann ich mich auch irren.^^

    Michael schrieb:

    torquato schrieb:

    Bei einer static-lib kommt es dadurch zu Problemen. 1.) die Lib und der restliche Code können unterschiedliche ABIs haben
    Wie bereits gesagt, das selbe Problem kannst du mit dynamischen auch Libraries haben.

    torquato schrieb:

    2.) es gibt 'duplicate symbols'.
    Warum?

    Ist ne technische Frage, wie der Linker funktioniert. Eine static-lib ist vollkommen für die Zielplattform durchkompiliert, mit allem was nötig ist, inklusive theoretisch notwendiger Teile einer Swift-stdlib. Beim verlinken werden alle Symbole ins Executable kopiert, und die Teile der stdlib sind dann doppelt vorhanden. Das mag ein Linker nicht.
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • torquato schrieb:

    Michael schrieb:

    torquato schrieb:

    gandhi schrieb:

    Und, BTW, kann man eigentlich in Swift eine static-library bauen?
    Klare Antwort: Nein.Zumindest z.Zt. noch nicht.

    Das hat folgenden Grund: Die ABI ist noch nicht festgelegt.
    Das bezweifle ich, denn das ABI-Problem betrifft dynamische Libraries/Frameworks ja genauso.
    U.A. aus diesem Grund verwendet Apple bisher auch noch keine in Swift geschriebene systemweite Libraries/ Frameworks. Mit dem nächsten Update (Sprache oder System) sind die nicht mehr kompatibel.
    Und, merkst du was? Das nicht festgelegte ABI kann, entgegen deiner Aussage, nicht der Grund sein, dass Swift keine statischen Libraries unterstützt, denn Frameworks kannst du ja jetzt schon in Swift bauen. Ich denke ja eher in die Richtung, dass Swift mit Modulen arbeitet.

    torquato schrieb:

    Michael schrieb:

    torquato schrieb:

    Eine stabile ABI ist auf Swift 4 verschoben worden, kommt also frühestens im Laufe 2017. Ohne stabile ABI macht es keinen Sinn, Swift-Bibliotheken im System zu verankern. Um Swift trotzdem frühstmöglich 'funktionsfähig' zu machen, greift Apple zu einem Trick und kompiliert die stdlib in die Excecutables hinein. Deshalb sind Swift Apps auch ohne Systemupdate auf Rechnern lauffähig.
    Nein, Apple kopiert diverse zum Executable ABI-kompatible, dynamische Swift-System-Libraries in das App-Bundle.
    Nein. Das funktioniert so auch mit CLI-tools. Die haben aber kein Bundle. Da kann nichts in ein Bundle reinkopiert werden. Es gibt keine libCoreSwift.dylib oder dergleichen unter Apple-Devices. Alles, was ein CLI-tool aus der Swift-stdlib braucht, wird z.Zt. tatsächlich ins Executable reinkompiliert/-kopiert.
    Stimmt, bei CLI-Tools ist das so. Bei App-Bundles nutzt Apple die dynamischen Libraries, um das ABI-Problem aufzulösen.

    torquato schrieb:

    Das, was Du da im App-Bundle siehst, sind m.W. Obj-C Cocoa Wrapper Stubs... Aber in dem Detail kann ich mich auch irren.^^
    Was in diesen Dingern drin steckt ist doch Wurscht. Sie werden aber erst beim Start der App zum Executable dynamisch hinzugelinkt. Sonst bräuchten die nicht in dem App-Bundle herum liegen.

    torquato schrieb:

    Michael schrieb:

    torquato schrieb:

    Bei einer static-lib kommt es dadurch zu Problemen. 1.) die Lib und der restliche Code können unterschiedliche ABIs haben
    Wie bereits gesagt, das selbe Problem kannst du mit dynamischen auch Libraries haben.

    torquato schrieb:

    2.) es gibt 'duplicate symbols'.
    Warum?
    Ist ne technische Frage, wie der Linker funktioniert. Eine static-lib ist vollkommen für die Zielplattform durchkompiliert, mit allem was nötig ist, inklusive theoretisch notwendiger Teile einer Swift-stdlib. Beim verlinken werden alle Symbole ins Executable kopiert, und die Teile der stdlib sind dann doppelt vorhanden. Das mag ein Linker nicht.
    Ob du „duplicate symbols“ bekommst oder nicht, hängt davon ab, was du da so zusammen linkst. Das klappt in diversen Programmiersprachen recht gut.

  • torquato schrieb:

    Amin Negm-Awad schrieb:

    Ein "recht frühes Entwicklungsstadium" hat die Versionsnummer 3.0?
    Versionsnummern sind Marketingblabla. Es soll sogar Software geben, deren Versionsnummern gegen Pi divergieren... :D
    Aha. Und zwei Jahre Verfügbarkeit sind dann auch nur Blabla?

    Mir erscheint eher "das wird in der nächsten Version dann brauchbar" Blabla zu sein. Wobei einem die Vergleichswerte fehlen.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    torquato schrieb:

    Amin Negm-Awad schrieb:

    Ein "recht frühes Entwicklungsstadium" hat die Versionsnummer 3.0?
    Versionsnummern sind Marketingblabla. Es soll sogar Software geben, deren Versionsnummern gegen Pi divergieren... :D
    Aha. Und zwei Jahre Verfügbarkeit sind dann auch nur Blabla?
    Mir erscheint eher "das wird in der nächsten Version dann brauchbar" Blabla zu sein. Wobei einem die Vergleichswerte fehlen.

    Und welche Relevanz hat jetzt Verfügbarkeit?
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • torquato schrieb:

    Amin Negm-Awad schrieb:

    torquato schrieb:

    Amin Negm-Awad schrieb:

    Ein "recht frühes Entwicklungsstadium" hat die Versionsnummer 3.0?
    Versionsnummern sind Marketingblabla. Es soll sogar Software geben, deren Versionsnummern gegen Pi divergieren... :D
    Aha. Und zwei Jahre Verfügbarkeit sind dann auch nur Blabla?Mir erscheint eher "das wird in der nächsten Version dann brauchbar" Blabla zu sein. Wobei einem die Vergleichswerte fehlen.
    Und welche Relevanz hat jetzt Verfügbarkeit?
    Stimmt natürlich. Für das "Alter" einer Software ist der Zeitraum der Verfügbarkeit unbedeutend. Man bemisst das vielmehr nach der Anzahl der Toilettengänge.

    WORAN DENN SONST?
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    torquato schrieb:

    Amin Negm-Awad schrieb:

    torquato schrieb:

    Amin Negm-Awad schrieb:

    Ein "recht frühes Entwicklungsstadium" hat die Versionsnummer 3.0?
    Versionsnummern sind Marketingblabla. Es soll sogar Software geben, deren Versionsnummern gegen Pi divergieren... :D
    Aha. Und zwei Jahre Verfügbarkeit sind dann auch nur Blabla?Mir erscheint eher "das wird in der nächsten Version dann brauchbar" Blabla zu sein. Wobei einem die Vergleichswerte fehlen.
    Und welche Relevanz hat jetzt Verfügbarkeit?
    Stimmt natürlich. Für das "Alter" einer Software ist der Zeitraum der Verfügbarkeit unbedeutend. Man bemisst das vielmehr nach der Anzahl der Toilettengänge.
    WORAN DENN SONST?
    Und welche Relevanz hat das Alter?

    Flash ist älter als HTML5. Basic ist älter als Java. Und das bedeutet jetzt genau was?
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • torquato schrieb:

    Amin Negm-Awad schrieb:

    torquato schrieb:

    Amin Negm-Awad schrieb:

    torquato schrieb:

    Amin Negm-Awad schrieb:

    Ein "recht frühes Entwicklungsstadium" hat die Versionsnummer 3.0?
    Versionsnummern sind Marketingblabla. Es soll sogar Software geben, deren Versionsnummern gegen Pi divergieren... :D
    Aha. Und zwei Jahre Verfügbarkeit sind dann auch nur Blabla?Mir erscheint eher "das wird in der nächsten Version dann brauchbar" Blabla zu sein. Wobei einem die Vergleichswerte fehlen.
    Und welche Relevanz hat jetzt Verfügbarkeit?
    Stimmt natürlich. Für das "Alter" einer Software ist der Zeitraum der Verfügbarkeit unbedeutend. Man bemisst das vielmehr nach der Anzahl der Toilettengänge.WORAN DENN SONST?
    Und welche Relevanz hat das Alter?
    Flash ist älter als HTML5. Basic ist älter als Java. Und das bedeutet jetzt genau was?
    Dass es sich bei Flash nicht um ein früheres Entwicklungsstadium handelt.

    Darauf hättest du aber selbst kommen können, oder?
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Amin Negm-Awad ()

  • macmoonshine schrieb:

    Amin Negm-Awad schrieb:

    Das es sich bei Flash nicht um eine früheres Entwicklungsstadium handelt.
    Das sehe ich anders: Flash ist war doch nie aus dem frühen Beta-Stadium herausgekommen. ;) +scnr+ :D
    Anders? Ist doch bei Swift genau so.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    macmoonshine schrieb:

    Amin Negm-Awad schrieb:

    Das es sich bei Flash nicht um eine früheres Entwicklungsstadium handelt.
    Das sehe ich anders: Flash ist war doch nie aus dem frühen Beta-Stadium herausgekommen. ;) +scnr+ :D
    Anders? Ist doch bei Swift genau so.
    Ich sprach nur über Flash und dessen Entwicklungsstand.
    „Meine Komplikation hatte eine Komplikation.“