Je suis un développeur C ++ et dans une tentative de mieux comprendre le développement multiplateforme, j'essaie de mieux comprendre certains détails d'implémentation des compilateurs et comment exactement ils créent des binaires spécifiques au système d'exploitation. Au milieu de mon étude, j'ai réalisé que, au moins pendant un certain temps, la plupart des compilateurs que vous avez téléchargés pour une plate-forme spécifique n'ont compilé que des binaires pour cette plate-forme. Donc, si vous avez téléchargé un IDE fourni avec un compilateur exe pour Windows, ce compilateur ne pourra compiler votre programme que pour les applications Windows x86-x64 et non pour les applications Linux ou Mac.
Maintenant, je comprends que différentes plates-formes nécessitent différents formats binaires, mais qu'est-ce qui rend difficile, par exemple, le compilateur C ++ visuel sous Windows pour générer un fichier exécutable binaire linux? Tant que vous avez les instructions d'assemblage pour le processeur sur lequel vous travaillez, ainsi que les bibliothèques spécifiques au système d'exploitation, ne devriez-vous pas être en mesure de compiler des exécutables pour n'importe quelle plate-forme sur n'importe quelle machine?
Réponses:
À part une réticence à le faire de la part de Microsoft, absolument rien. Les obstacles ne sont pas techniques.
Les chaînes d'outils de développement ne sont que des programmes qui prennent des entrées et produisent des sorties. Visual C ++ produit un assemblage x86, puis utilise un assembleur pour le convertir en un fichier objet COFF. Si Microsoft voulait plutôt le faire générer ELF, c'est juste du code: l'assemblage entre, ELF s'éteint. Il n'y a rien de magique dans les fichiers objets ou les bibliothèques; ce ne sont que des taches de données dans un format bien compris.
À l'époque de la pierre, la compilation croisée était beaucoup plus difficile car, le plus souvent, vous auriez écrit la chaîne d'outils de votre plate-forme cible en l'assemblant pour la plate-forme où elle s'exécuterait. Cela signifiait que si tout ce qu'il y avait dans le monde était les architectures VAX, M68K et Alpha, une suite complète de compilateurs croisés nécessiterait d'en écrire neuf, la plupart à partir de zéro. (VAX à VAX, VAX à M68K, VAX à Alpha, M68K à VAX, M68K à M68K, etc.) C'est un peu exagéré car certaines parties du compilateur VAX pourraient être réutilisées et attaché aux générateurs de code pour chaque cible (par exemple, VAX, M68K et Alpha, chacun écrit pour VAX.)
Ce problème a disparu lorsque nous avons commencé à écrire des compilateurs dans un langage qui n'était pas lié à un processeur spécifique, un tel C.Cette voie signifie que vous écrivez la chaîne d'outils entière une fois en C et utilisez une plate-forme écrite pour la plate-forme locale Compilateur C pour le construire. (Vous utiliseriez souvent le compilateur pour se recompiler après avoir été amorcé sur le compilateur de la plate-forme locale, mais c'est une autre discussion.) Le résultat est que la construction d'un compilateur croisé est devenue essentiellement le même effort que la construction d'un compilateur natif sur la plateforme locale. La seule différence significative est que quelque part dans le processus de construction, vous lui avez dit de compiler dans le générateur de code pour votre plate-forme cible au lieu de celui pour la plate-forme locale, ce qui aurait été le choix logique.
À mesure que l'architecture des compilateurs évoluait, il devenait pratique d'inclure et de construire simplement tous les générateurs de code avec le produit et de sélectionner celui qui sera utilisé au moment de l'exécution. Clang / LLVM fait cela, et je suis sûr qu'il y en a d'autres.
Une fois que vous avez une chaîne d'outils fonctionnelle (compilateur, assembleur, éditeur de liens), les bibliothèques sont construites à partir de sources et, finalement, vous vous retrouvez avec tout ce dont vous avez besoin pour produire un fichier exécutable pour une autre plate-forme.
la source
What would be the business benefit ... I don't think there is any.- Cela semble être une bonne raison de ne pas vouloir le faire.Oui, si vous avez toutes les informations sur votre plate-forme cible, peu importe sur quelle plate-forme vous utilisez réellement.
Il y a deux problèmes qui ont tendance à surgir:
Ce ne sont bien sûr pas insurmontables. Généralement, vous obtenez des compilateurs qui ciblent la plate-forme sur laquelle ils s'exécutent, car c'est ce que les gens veulent.
la source
Je suis en désaccord avec votre prémisse. Il y a des millions de développeurs Android et iOS. Et ils utilisent tous des compilateurs fonctionnant sous Windows ou un Mac, produisant du code pour un ordinateur entièrement différent.
Vous n'obtiendrez pas de compilateur croisé s'il n'y a pas de demande sur le marché. Les personnes développant du code pour un bureau Linux, par exemple, ont généralement un bureau Linux disponible et utiliseront un compilateur basé sur Linux - beaucoup plus rapide si vous pouvez exécuter votre application directement sur la machine où elle est compilée sans la transporter sur le réseau, beaucoup plus facile et plus rapide d'avoir un débogueur en cours d'exécution sur la même machine et ainsi de suite.
Alors, combien d'argent gagnerait Microsoft si leurs compilateurs construisaient également pour Linux? Environ 0 $. Combien de logiciels supplémentaires pour Windows seraient créés? Aucun. Combien de logiciels Linux supplémentaires seraient créés? Aucune idée, mais ce n'est pas quelque chose dont Microsoft se soucie. Quel serait le coût? Assez considérablement. Les compilateurs doivent être exempts de bogues. Ils doivent être testés.
Un autre problème: si vous écrivez un compilateur écrivant sur Windows, vous avez besoin de quelqu'un qui sait écrire un logiciel Windows. Si vous écrivez un compilateur pour Linux, vous avez besoin de quelqu'un qui sait écrire un logiciel Linux. Si vous écrivez un compilateur pour Linux fonctionnant sous Windows, vous avez soudainement besoin du pain beaucoup plus rare de développeur qui connaît à la fois Windows et Linux.
la source