Salut
Un truc me turlupine, pourquoi quand on doit installer un prog, sous GNU/Linux, dit-on “Compiler” ?
Merçi
Non quand on installe on installe , quand on compile on compile 
Et oui. Soit on installe un programme déjà compilé, soit on le compile soi-même, et ensuite, on l’installe. 
Hey, The maurice, tu serais pas un descendant de Lapalisse ?
Quand tu part d’un fichier source (fichier texte) pour créer un exécutable, tu dois
- utiliser un compilateur qui transforme le source en cible
- accrocher les bibliothèques, ça se disait "linker"
Et là tu avais ton exécutable.
Installer signifie plutôt, copier des bouts de l’exécutable et de ses dépendances au bon endroit sur ta machine, pour que ça tourne et parametrer ses bouts.
Bien sur les languages interprétés rendent tout ça caduc …
Si tu part d’un Tar.gz
compiler
linker
installer
Ces procédures sont cachés par les scripts de type “configure” et “make”, qui font les trois pour toi et tant mieux.
ça date de la préhistoire de l’informatique, et ça dure…
Compiler est une reprise savante du mot compiler utilisé en général pour les livres (rassembler dans un seul contenant des contenus de même nature) mais qui a repris dans le sens informatique au plus prés son sens étymologique originel grec de “condenser, fouler ensemble”.
Le compilateur condense en effet ensemble tout un texte formé d’instructions à executer (qu’on nomme aussi, du point de vue de la machine, son programme, et du point de vue du lecteur, le code source) qui est écrit en langage dit évolué ou de haut niveau, pour produire un jeu d’instructions directement utilisé par le processeur pour lequel il est prévu (jeu d’instructions machine qu’on appelle un executable ou une bibliothèque) en général plus compact que le code source et contenant toute la traduction de ce même code source.
A distinguer d’un interprèteur qui ne transforme le code source en instructions machine que phrase à phrase et qui execute ces séquences d’instruction au moment ou il les interprète.
A noter qu’entre les deux, il existe la notion de précode ou P-Code qui oblige à compiler un source dans un langage intermédiaire trés compact, qu’interprète ensuite un moteur qui fournit les APIs qui complètent le p-code avec les routines de bibliothèque pour l’envoyer pas à pas au processeur.
En fait, toute la tâche de traduction d’un programme pensé et décrit dans un langage compréhensible par l’être humain en un jeu d’instruction précis executées par la machine peut être finement découpé en plusieurs étapes (analyse, transcodage, optimisation, génération de code objet, lien avec du code objet exterieur factorisant les sous programmes entre les applications, execution) et on peut dire que ces trois manières de faire tout ce trajet ne diffèrent finalement que par le nombre arbitraire d’étapes apparentes lors de l’action qui mène à l’execution. J’imagine qu’il y a encore d’autres manières de découper les étapes de cette traduction que je ne connais pas.
Ben en gros il y a
- l’analyse lexicale: convertissant la chaine de caractères en une suite de mots clefs (lex)
- l’analyse syntaxique: convertissant la suite de mots clefs en un arbre dit syntaxique (parsage), (c’est le boulot de yacc).
- Ce qu’on pourrait appelé l’analyse sémantique ou évaluation de l’arbre: Ça peut être l’éxécution (interpréteur), la production d’un code (compilateur), la traduction dans un autre langage, l’affichage sur écran (emacs), etc.
Ce sont les 3 étapes que je vois et qui se retrouve partout. Pour moui, il n’y a guère de différence entre un interpréteur et un compilateur.
typage aussi après les analyses lexicales et syntaxiques (enfin souvent). Et dans le cas d’une compilation pour produire un exécutable en vue de l’ “installer” (pour essayer de caler le plus possible au sujet), par la suite, tu as généralement une série d’opérations visant à transformer le résultat des analyses lexicales et syntaxiques en code dit “intermédiaire”, générique pour le compilateur, puis une série d’opérations utilise ensuite ce code intermédiaire, inutilisable par une machine directement, pour produire du code assembleur spécifique à une architecture donnée puis un binaire exécutable (d’ou certains problèmes de compatibilité / incompatibilités entre architectures).
(Oui ca se voit que j’en ai bouffé tout un semestre de ce modèle précis 
).
[quote=“Hoshin”]typage aussi après les analyses lexicales et syntaxiques (enfin souvent).
[/quote]
Le typage fait partie intégrante de l’analyse syntaxique [edit: j’avais marqué lexicale ce qui est faux] et est même sa composante essentielle.
Ça… la compilation passe effectivement par plusieurs étapes surtout si t’y rajoutes un code intermédiaire puis de l’optimisation. Je ne connais pas très bien cette partie là…
C’est vrai je sépare mécaniquement le typage parceque dans le projet que l’on avait cette année le typage était “optionnel” et traité à part (il n’était pas absolument nécessaire) donc j’ai pris la “mauvaise” habitude de séparer les 2.
Le code intermédiaire est surtout utile pour pouvoir différencier le coeur du backend du compilo si j’ai à peu près suivi le cours, le coeur faisant une compilation qui ne tient pas compte de l’architecture et le backend adaptant le code intermédiaire fourni par le coeur à une architecture spécifique… avec des choses sympa comme l’allocation des registres de l’archi concernée par divers algos dont le, apparament, très utilisé coloriage de graphe … moi perso j’ai commencé à nager au niveau du code intermédiaire ^^
M’enfin de toute façon ca sort du cadre de la question ce que je déblatère. Comme il a été dit plus tot, compilation et installation ne sont pas la même chose, on peut compiler sans “installer” et inversement :
L’installation de nos chers .deb est justement l’installation “de paquets” consistant à placer aux endroits qu’il faut divers fichiers dont éventuellement des binaires exécutables précompilés pour une certaine architecture si je ne me trompe pas.
Par contre la compilation du bon vieux “hello_world.c” n’installe rien en particulier, elle permet juste d’afficher un message de son choix dans son terminal en guise de premier programme C ^^.
quote="Hoshin"
L’installation de nos chers .deb est justement l’installation “de paquets” consistant à placer aux endroits qu’il faut divers fichiers dont éventuellement des binaires exécutables précompilés pour une certaine architecture si je ne me trompe pas.
(…)[/quote]Exact, mais c’est oublier un peu vite qu’on peut encore optimiser ses paquets en les installant depuis les sources. Le plus simple (mais le plus bugué AMA) pour ça, c’est quand même d’installer apt-build et de configurer son apt-build.conf pour choisir ses flags, puis d’installer ses paquets par compil, comme avec apt-get: apt-build install
et bien sûr, vs oubliez tjrs le principal, sans lequel rien ne serait possible :
le mec qui a planté l’arbre
avec lequel on a fait le papier
sur lequel l’analyste a écrit le texte
qui a été converti par le programmeur
…
Tjrs la m^ chose, gloire aux ‘scribouillards’ et ‘pfttttt !’ aux manuels. 
rhoooo tout de suite ricardo, en meme temps si on veut parler de “manuel” dans la compil … faut remonter à la fabrication de la machine (qui n’est pas automatisée de surcroit) et ca commence à faire long comme retour en arrière ^^ … ou parler du man … mais la pour le coup le côté “fait main” est un peu zappé (enfin c’est tapé à la main quoi )
@matt : m’en souvenais pas de apt-build, on en apprend tous les jours (surtout moi en ce moment). Mais pourquoi est-ce “buggé” ? Y’a pas de façon universelle de choisir ses flags de compilation et c’est le fait de tenter d’automatiser qui rend le schmilblick hasardeux ? Ou c’est tout à fait autre chose ?
quote=“Hoshin”
@matt : m’en souvenais pas de apt-build, on en apprend tous les jours (surtout moi en ce moment). Mais pourquoi est-ce “buggé” ? Y’a pas de façon universelle de choisir ses flags de compilation et c’est le fait de tenter d’automatiser qui rend le schmilblick hasardeux ? Ou c’est tout à fait autre chose ?[/quote] Non, simplement, par exemple il prend trés mal en charge les préfèrences, et télécharge la version la plus récente des sources quelles que soient les preferences puis essaye ensuite de compiler la version qui normalement devrait être sélectionnée, et bien évidemment il plante parcequ’il a une version differente des sources.
Mais même l’auteur le dit, si je m’en souviens bien dans la page de man, à la section BUGS, il dit “many”
J’ai d’ailleurs un peu l’impression que le paquet est orphelin, ou que le développeur a d’autres choses à faire, parceque pas grand chose n’a bougé dessus depuis 3 ans que je le connais. Faudrait voir les changelogs, p.e. que le pb de preferences est corrigé maintenant, mais aux dernières nouvelles, il ne l’était pas.