Stations de travail en ligne OnWorks Linux et Windows

Logo

Hébergement gratuit en ligne pour les postes de travail

<Précédent | Table des matières | Suivant>

Construire le programme

La plupart des programmes se construisent avec une simple séquence de deux commandes :



./configurer faire

./configurer faire


Le configurer est un script shell fourni avec l'arborescence des sources. Son travail consiste à analyser les environnement de construction. La plupart des codes sources sont conçus pour être portable. C'est-à-dire qu'il est conçu pour s'appuyer sur plus d'un type de système de type Unix. Mais pour ce faire, le code source devra peut-être subir de légers ajustements pendant la construction pour tenir compte des différences entre les systèmes. configurer vérifie également que les outils et composants externes nécessaires sont installés. Courons configurer. Depuis configurer n'est pas situé là où le shell s'attend normalement à ce que les programmes soient situés, nous devons explicitement indiquer au shell son emplacement en préfixant la commande avec ./ pour indiquer que le programme se trouve dans le répertoire de travail courant :



[moi@linuxbox diction-1.11]$ . / Configure

[moi@linuxbox diction-1.11]$ . / Configure


configure affichera beaucoup de messages pendant qu'il teste et configure le build. Une fois terminé, cela ressemblera à quelque chose comme ceci :



vérification de la présence de libintl.h... oui vérification de la présence de libintl.h... oui

vérification de la bibliothèque contenant gettext... aucun requis configure: creation ./config.status

config.status : création de Makefile config.status : création de diction.1 config.status : création de diction.texi config.status : création de diction.spec config.status : création de style.1 config.status : création de test/rundiction config.status : création de config.h [me@linuxbox diction-1.11]$

vérification de la présence de libintl.h... oui vérification de la présence de libintl.h... oui

vérification de la bibliothèque contenant gettext... aucun requis configure: creation ./config.status

config.status : création de Makefile config.status : création de diction.1 config.status : création de diction.texi config.status : création de diction.spec config.status : création de style.1 config.status : création de test/rundiction config.status : création de config.h [me@linuxbox diction-1.11]$


Ce qui est important ici, c'est qu'il n'y a pas de messages d'erreur. Si c'était le cas, la configuration a échoué et le programme ne sera pas construit tant que les erreurs ne seront pas corrigées.

Nous voyons configurer créé plusieurs nouveaux fichiers dans notre répertoire source. Le plus important est Makefile. Makefile est un fichier de configuration qui indique au a prendre une programme exactement comment construire le programme. Sans ça, a prendre une refusera de courir. Makefile est un fichier texte ordinaire, nous pouvons donc le visualiser :



[moi@linuxbox diction-1.11]$ moins de Makefile

[moi@linuxbox diction-1.11]$ moins de Makefile


Le a prendre une programme prend en entrée un makefile (qui s'appelle normalement Makefile), qui décrit les relations et les dépendances entre les composants qui composent le programme fini.

La première partie du makefile définit les variables qui sont substituées dans les sections ultérieures du makefile. Par exemple, nous voyons la ligne :



CC= gcc

CC= gcc


qui définit le compilateur C comme étant gcc. Plus tard dans le makefile, nous voyons une instance où il est utilisé :


diction:

diction.o phrase.o misc.o getopt.o getopt1.o

$(CC) -o $@ $(LDFLAGS) diction.o phrase.o misc.o \ getopt.o getopt1.o $(LIBS)

diction:


image

Une substitution est effectuée ici, et la valeur $(CC) est remplacé par gcc au moment de l'exécution.

image

La plupart du makefile se compose de lignes, qui définissent un l'objectif, dans ce cas le fichier exécutable diction, et les fichiers dont il dépend. Les lignes restantes décrivent la ou les commandes nécessaires pour créer la cible à partir de ses composants. On voit dans cet exemple que le fichier exécutable diction (l'un des produits finaux) dépend de l'existence de diction.o, phrase.o, divers.o, getopt.oet une getopt1.o. Plus tard, dans le makefile, nous voyons les définitions de chacun d'eux en tant que cibles :


diction.o :

getopt.o : getopt1.o : misc.o :

diction.c config.h getopt.h misc.h phrase.h

getopt.c getopt.h getopt_int.h getopt1.c getopt.h getopt_int.h misc.c config.h misc.h

diction.o :

getopt.o : getopt1.o : misc.o :


phrase.o :

style.o :

phrase.c config.h misc.h phrase.h

style.c config.h getopt.h misc.h phrase.h

phrase.o :

style.o :


image

Cependant, nous ne voyons aucune commande spécifiée pour eux. Ceci est géré par une cible générale, plus tôt dans le fichier, qui décrit la commande utilisée pour compiler n'importe quel .c fichier dans un .o fichier:



.co:

$(CC) -c $(CPPFLAGS) $(CFLAGS) $

.co:

$(CC) -c $(CPPFLAGS) $(CFLAGS) $


Tout cela semble très compliqué. Pourquoi ne pas simplement lister toutes les étapes pour compiler les pièces et en finir avec ? La réponse à cela deviendra claire dans un instant. En attendant, courons a prendre une et construisons nos programmes :


[moi@linuxbox diction-1.11]$ a prendre une

[moi@linuxbox diction-1.11]$ a prendre une


Le a prendre une programme s'exécutera, en utilisant le contenu de Makefile pour guider ses actions. Cela produira beaucoup de messages.

Lorsqu'il sera terminé, nous verrons que toutes les cibles sont désormais présentes dans notre répertoire :



[moi@linuxbox

diction-1.11]$ ls

config.deviner

entrepôt

en

installer-sh

phrase.c

config.h

diction

en_GB

Makefile

phrase.h

config.h.in

diction.1

fr_FR.mo

Makefile.in

phrase.o

config.log

diction.1.in

fr_FR.po

divers.c

Catégorie

config.statut

diction.c

getopt1.c

divers.h

style.1

config.sub

diction.o

getopt1.o

divers.o

style.1.in

configurer

diction.pot

getopt.c

NOUVELLES

style.c

configurer.in

diction.spec

getopt.h

nl

style.o

COPIER

diction.spec.in

getopt_int.h

nl.mo

tester

de

diction.texi

getopt.o

nl.po

démo

diction.texi.in

INSTALLER

README


Parmi les fichiers, on voit diction et les Catégorie, les programmes que nous avons entrepris de construire. Les félicitations s'imposent ! Nous venons de compiler nos premiers programmes à partir du code source !

Mais juste par curiosité, courons a prendre une encore:


[moi@linuxbox diction-1.11]$ a prendre une

make : rien à faire pour « tous ».

[moi@linuxbox diction-1.11]$ a prendre une

make : rien à faire pour « tous ».


Il ne produit que ce message étrange. Ce qui se passe? Pourquoi n'a-t-il pas recréé le programme ? Ah, c'est la magie de a prendre une. Plutôt que de simplement tout reconstruire, a prendre une ne construit que ce qui doit être construit. Avec toutes les cibles présentes, a prendre une déterminé qu'il n'y avait rien à faire. Nous pouvons le démontrer en supprimant l'une des cibles et en exécutant à nouveau make pour voir ce qu'elle fait. Débarrassons-nous d'une des cibles intermédiaires :



[moi@linuxbox diction-1.11]$ rm getopt.o

[moi@linuxbox diction-1.11]$ a prendre une

[moi@linuxbox diction-1.11]$ rm getopt.o

[moi@linuxbox diction-1.11]$ a prendre une


On voit ça a prendre une le reconstruit et reconnecte le diction et les Catégorie programmes, car ils dépendent du module manquant. Ce comportement souligne également une autre caractéristique importante de a prendre une: il maintient les cibles à jour. a prendre une insiste pour que les cibles soient plus récentes que leurs dépendances. Cela est parfaitement logique, car un programmeur mettra souvent à jour un peu de code source, puis utilisera a prendre une pour construire une nouvelle version du produit fini. a prendre une garantit que tout ce qui doit être construit sur la base du code mis à jour est construit. Si nous utilisons le -nous programme pour « mettre à jour » l'un des fichiers de code source, nous pouvons voir cela se produire :



[moi@linuxbox diction-1.11]$ ls -l diction getopt.c

-rwxr-xr-x 1 moi moi 37164 2009-03-05 06:14 diction

-rw-r--r-- 1 moi moi 33125 2007-03-30 17:45 getopt.c [me@linuxbox diction-1.11]$ touchez getopt.c

[moi@linuxbox diction-1.11]$ ls -l diction getopt.c

-rwxr-xr-x 1 moi moi 37164 2009-03-05 06:14 diction

-rw-r--r-- 1 moi moi 33125 2009-03-05 06:23 getopt.c [me@linuxbox diction-1.11]$ a prendre une

[moi@linuxbox diction-1.11]$ ls -l diction getopt.c

-rwxr-xr-x 1 moi moi 37164 2009-03-05 06:14 diction

-rw-r--r-- 1 moi moi 33125 2007-03-30 17:45 getopt.c [me@linuxbox diction-1.11]$ touchez getopt.c

[moi@linuxbox diction-1.11]$ ls -l diction getopt.c

-rwxr-xr-x 1 moi moi 37164 2009-03-05 06:14 diction

-rw-r--r-- 1 moi moi 33125 2009-03-05 06:23 getopt.c [me@linuxbox diction-1.11]$ a prendre une


Après a prendre une s'exécute, nous voyons qu'il a restauré la cible pour qu'elle soit plus récente que la dépendance :



[moi@linuxbox diction-1.11]$ ls -l diction getopt.c

-rwxr-xr-x 1 moi moi 37164 2009-03-05 06:24 diction

-rw-r--r-- 1 moi moi 33125 2009-03-05 06:23 getopt.c

[moi@linuxbox diction-1.11]$ ls -l diction getopt.c

-rwxr-xr-x 1 moi moi 37164 2009-03-05 06:24 diction

-rw-r--r-- 1 moi moi 33125 2009-03-05 06:23 getopt.c


La capacité de a prendre une construire intelligemment uniquement ce qui doit être construit est un grand avantage pour les programmeurs. Même si le gain de temps n'est peut-être pas très apparent avec notre petit projet, il


est très important avec des projets plus importants. N'oubliez pas que le noyau Linux (un programme qui subit des modifications et des améliorations continues) contient plusieurs million lignes de code.


Meilleur système d'exploitation Cloud Computing chez OnWorks :