Apple kündigt die Open-Source-Veröffentlichung von Swift Build an

• Swift gewinnt als Sprache mit Unterstützung für verschiedene Plattformen an Beliebtheit und kann auf unterschiedlichen Embedded-Geräten und Betriebssystemen eingesetzt werden
• Apple veröffentlicht mit Swift Build eine leistungsstarke und skalierbare Build-Engine als Open Source
• Swift Build wird als Build-Engine von Xcode verwendet und kommt auch beim „Build von App-Store-Apps und Apples eigenen Betriebssystemen“ zum Einsatz.
  • Unterstützt auch Target-Builds für Linux und Windows

• Kernfunktionen von Swift Build

  • Ein Build-System wandelt Projektbeschreibungen und Quellcode in Ausgabeartefakte wie Kommandozeilen-Tools, Bibliotheken und Anwendungen um
  • Swift Build ist eine Infrastrukturkomponente, die von übergeordneten Clients wie Swift Package Manager oder Xcode angeforderte Builds plant und ausführt
  • Durch die enge Integration mit dem Swift-Compiler koordiniert es Builds von Swift-Projekten zuverlässig und effizient
  • Unterstützt verschiedene Produkttypen und bietet erweiterte Optionen für die Build-Konfiguration
  • Enthält Optimierungen des Build-Graphen, um die Parallelität beim Bauen von Swift- und C-Code zu maximieren

• Roadmap für Swift Build

  • Im Vergleich zur Build-Engine von Xcode ist die Build-Engine des Swift Package Managers relativ einfach
  • Zwei unterschiedliche Methoden zum Bauen von Paketen auf Apple-Plattformen haben bei Nutzern für Verwirrung gesorgt
  • Apple möchte diese Probleme lösen, indem die Build-Engine von Xcode zu Swift-Projekten beigetragen und zusammen mit dem Swift-Compiler als Open Source entwickelt wird
  • SwiftPM erhält damit die Möglichkeit, auf allen Plattformen eine einheitliche Engine für die Build-Ausführung bereitzustellen
  • Diese Änderung wirkt für Nutzer transparent und bewahrt die vollständige Kompatibilität mit allen bestehenden Paketen
  • Damit wird die Grundlage geschaffen, neue Funktionen und Verbesserungen über alle Plattformen und Tools hinweg bereitzustellen
  • Ein PR zur Integration von Swift Build als alternative Build-Engine von SwiftPM wurde eingereicht
  • In Zusammenarbeit mit der Community möchte man die Integrationsarbeiten am Build-System abschließen, damit künftige Tooling-Verbesserungen auf allen Plattformen und in allen Projektmodellen nutzbar werden

• Einladung zur Mitwirkung

  • Man freut sich auf die Zusammenarbeit mit der Community, um die Art und Weise, wie Swift-Code gebaut wird, weiterzuentwickeln.
  • Im swift-build-Repository der Swift-Organisation auf GitHub finden sich eine README und Dokumentation, die Build- und Beitragswege erläutern.
  • Beiträge per Pull Request und Issue sind willkommen, und im Swift-Forum möchte man Feedback und Ideen für Verbesserungen erhalten.
  • Dies ist ein spannendes neues Kapitel für das Build-System von Swift, von dem man erwartet, dass es das volle Potenzial von Swift erschließt.

[ganadist]

Auf Seite 12 von https://llvm.org/devmtg/2016-11/… scheint der wichtige Inhalt zu stehen.

Traditionelles UNIX-Compiler-/Build-System-Modell
• Der Compiler läuft als separater Prozess
• Primitive Mechanismen zur Kommunikation von Abhängigkeiten
• Feste Eingabe-/Ausgabe-Pipeline, die über die Kommandozeile definiert ist
• Das ist eine API ...
• ... und wir haben sie seit Jahrzehnten nicht verändert
• Wir ❤ es, APIs aufzubrechen

Auf der Java-Seite scheint es eine API zu geben, die Abhängigkeiten zwischen Code mitteilt, sodass Build-Tools erfahren, wie ein Incremental Build möglich wird,
z. B.: Gradle

Es sieht so aus, als sollte man diesen Ansatz auch auf Native-Builds anwenden.

[nemorize]

Also ... kurz gesagt heißt das, dass Xcode nach wie vor genauso viel Schrott ist wie bisher, oder?
schnief

[roxie]

zzz

[GN⁺]

Hacker-News-Kommentare

• Die Wahrnehmung, dass Swift „für alles gut, aber besser für Apple-Plattformen“ sei, könnte der Sprache schaden. Das zieht nicht mehr Menschen in das Swift-Ökosystem

  • Die Konkurrenz ist stärker Open Source, hat mehr Mitwirkende und einen engeren Fokus
  • Wenn Tools wie Xcode nicht Open Source werden, wird der Abstand zu anderen Sprachen größer werden

• Swift ist eine tolle Sprache

  • Bei einem Fehler wie index out of range zeigt die Fehlermeldung nicht an, wo er aufgetreten ist
  • Golang nennt die Datei und die Zeilennummer, in der der Fehler aufgetreten ist

• Die Situation von Swift erinnert an die frühen Tage von C#

  • Auch C# wurde als Open Source und plattformübergreifend beworben, blieb aber hinter den Erwartungen zurück

• Es wäre wünschenswert, wenn Swift auf allgemeinem LLVM statt auf Apples LLVM-Fork aufgebaut wäre

• Swift sollte eine Entkopplung von Xcode anstreben

  • Xcode ist mit 3,1 Punkten in gewisser Weise überbewertet

• Die neue Veröffentlichung von SwiftPM bietet die Chance, eine vereinheitlichte Build-Ausführungs-Engine für alle Plattformen bereitzustellen

  • Das wird der Schlüssel zum Aufbau eines plattformübergreifenden Swift-Ökosystems sein

• Es ist fraglich, ob damit ein Weg für Swift-Entwicklung ohne Xcode eröffnet werden kann

• Es ist nicht klar, wie gut Swift Build in Swifts Tools und Language Server integriert ist

  • Der Language Server ist bereits Open Source

• Es freut mich, dass Swift unabhängiger von Apple wird

  • In einem plattformübergreifenden Projekt ließ sich URLSession.shared.data unter Linux nicht kompilieren, weshalb ich zu einer anderen Sprache gewechselt bin

• Ich frage mich, ob Swift es mit Embedded-Systemen ernst meint