- Swift prend en charge non seulement les plateformes Apple, mais aussi Linux, Windows, etc.
- Avec le SDK Linux statique pour Swift, il est possible de compiler des exécutables entièrement liés statiquement, sans dépendances externes
- Ils peuvent ainsi s’exécuter sur toutes les distributions Linux
- On peut développer et tester sur macOS, puis déployer sur des serveurs basés sur Linux
- L’édition de liens est le processus qui consiste à rassembler différentes parties d’un programme et à résoudre les références
- L’édition de liens statique se fait à la compilation, tandis que l’édition de liens dynamique se fait à l’exécution
- Une bibliothèque statique est un ensemble de fichiers objets individuels, tandis qu’une bibliothèque dynamique est monolithique
- Avantages et inconvénients de l’édition de liens statique :
- Avantages : pas de surcoût à l’exécution, inclusion uniquement du code des bibliothèques nécessaire, pas besoin de bibliothèques dynamiques installées séparément, pas de problèmes de version à l’exécution
- Inconvénients : pas de partage de code (augmentation de l’usage mémoire), impossible de mettre à jour les dépendances sans recompiler le programme, taille de l’exécutable plus importante
- Sur Linux, l’édition de liens statique permet d’éliminer complètement les dépendances aux bibliothèques système propres à chaque distribution
- Il faut installer la toolchain Open Source depuis swift.org (la toolchain fournie par Xcode ne peut pas être utilisée)
- Le SDK Linux statique peut être installé avec la commande
swift sdk install
- La commande
swift build --swift-sdk x86_64-swift-linux-musl permet de compiler un binaire Linux x86-64, et la commande swift build --swift-sdk aarch64-swift-linux-musl permet de compiler un binaire Linux ARM64
- Les paquets Swift qui utilisent Foundation ou Swift NIO fonctionnent tels quels
- Les paquets qui utilisent des bibliothèques C doivent être modifiés pour importer Musl au lieu de Glibc
- Musl prend bien en charge l’édition de liens statique et dispose d’une licence permissive qui facilite la distribution des exécutables
- Les dépendances d’un paquet peuvent être modifiées avec la commande
swift package edit
2 commentaires
On dirait que ça va permettre de voir arriver quelque chose qui prenne en charge de façon plus fluide le développement simultané Android et iOS avec Swift…
Avis Hacker News
Nouveau support de plateformes personnalisées dans Swift : le fait que Swift prenne en charge les systèmes embarqués et le WASM, et qu’il ait été déplacé vers une organisation GitHub non liée à Apple, constitue une avancée majeure pour étendre Swift à d’autres plateformes. Son utilisation potentielle pour la vérification de sécurité d’un OS d’IA est également intéressante.
Exécution possible de binaires Swift dans des conteneurs Alpine : ravi de pouvoir exécuter des binaires Swift dans des conteneurs Alpine. Le travail sur la prise en charge de musl avance plus vite que prévu. La compilation croisée est aussi très utile.
Attentes autour du support de Debian : heureux de voir des paquets Swift ajoutés à Debian. J’ai l’impression que je vais utiliser davantage Debian comme VM de développement.
Hâte d’utiliser Swift sur des systèmes embarqués : j’ai beaucoup travaillé sur l’embarqué en C, mais j’aimerais essayer Swift sur une carte de développement STM.
Inconvénients du lien statique : l’ASLR ne fonctionne pas correctement, ou bien un seul objet est randomisé. Ce n’est peut-être pas un gros inconvénient avec un langage sûr en mémoire. Le partage d’objets communs peut réduire les E/S.
Problèmes de compatibilité entre distributions : un programme compilé sur une distribution ou une version donnée peut ne pas fonctionner sur une autre. C’est bien que Swift propose le lien statique, mais le mieux est que les distributions puissent choisir leur mode de distribution des paquets.
Potentiel de concurrence avec Golang : Swift pourrait rivaliser avec Golang sur la facilité de déploiement. Cela repousse la complexité loin de l’utilisateur final.
Applications GUI multiplateformes : je me demande ce que donnerait la création d’applications GUI multiplateformes en Swift. SwiftUI ne semble probablement pas utilisable, mais je compte utiliser Swift pour écrire de petits scripts.
Avertissement sur l’usage des images CentOS 7 : continuer à proposer des images CentOS 7 semble insensé. Avertissement : ne pas les utiliser.
Complexité croissante de Swift : Swift aurait pu facilement remplacer Python, mais le langage s’est complexifié au point de devenir désormais une sorte de sous-produit de C++.
Pourquoi utiliser Swift plutôt que Rust ? : question sur les raisons d’utiliser Swift au lieu de Rust.
Pourquoi utiliser Swift sans iOS/SwiftUI ? : question sur l’intérêt d’utiliser Swift sans iOS/SwiftUI. Il ne semble pas y avoir vraiment de raison, sauf pour un développeur Swift qui veut utiliser un langage familier pour de petits projets.