Oui et non. Oui, le scénario classique est un développeur utilisant un compilateur pour générer du code machine à partir du code source, et le code machine est ensuite distribué aux utilisateurs.
Il y a cependant quelques exceptions. Tout d'abord, de nombreux projets open source sont distribués principalement (ou même exclusivement) sous forme de code source, et attendent de l'utilisateur final qu'il les installe en tapant quelques commandes comme make
, puismake intall
. Cela invoquera le compilateur, l'éditeur de liens, etc., pour générer le code machine à partir du code source de l'ordinateur de cet utilisateur. Dans ces cas, cependant, le processus de construction et d'installation est (au moins destiné à être) automatisé au point que l'utilisateur a rarement besoin de beaucoup de connaissances au-delà du fait que s'il n'a jamais installé un package de code source uniquement auparavant , leur gestionnaire de packages répertorie généralement certains packages de "développement" comme une condition préalable à l'installation de l'application qui leur tient vraiment à cœur (bien que certains considèrent toujours cela comme hostile pour les utilisateurs finaux).
Une autre exception (à laquelle on a fait allusion, mais qui n'est pas très bien expliquée dans les autres réponses que j'ai vues) concerne les compilateurs juste à temps (JIT). Quelques exemples évidents de compilateurs JIT sont le Microsoft Common Language Runtime (CLR) et la machine virtuelle Java (JVM). Dans ces cas, il y a normalement deux compilateurs entièrement distincts impliqués dans la traduction du code source en code machine. L'un est utilisé par le développeur. Cependant, plutôt que de générer directement du code machine, il génère un code octet indépendant de la machine. Le CLR / JVM comprend ensuite un deuxième compilateur, entièrement distinct du premier, qui convertit ces codes d'octets en code machine pour l'ordinateur cible.
Je dois ajouter que le deuxième compilateur n'est pas strictement nécessaire. Les premières versions de la JVM (par exemple) venaient d'interpréter les codes d'octets au lieu de les compiler. Cependant, cela entraîne souvent une pénalité de performances assez grave, de sorte que la plupart des machines virtuelles Java relativement récentes destinées à la production incluent un compilateur JIT.