Makefile - Page 1

Un makefile ne recompile que ce qui a été modifié (KTIGCC aussi, d'ailleurs).

Je vais prendre le cas de Tim, mon V4p0r shell qui est certes un peu particulier.

Il est constitué d'un programe principal(en fait juste un lanceur) et de plusieurs libs kernel que je charge avec les lib conditionelles. il peu s'agir de vraies bibliothèques, de plugins(simple ou complexes) ou même du corps du programme principal(pour pouvoir le décharger à l'exécution d'un programme)
Là TIGCC-IDE n'est pas vraiment adapté car pour TIGCC-IDE : un projet = un binaire, or j'ai plein de binaires.
Le makefile est très pratique pour être sur que je ne recompile que les éléments que j'ai modifié tout en étant sur de ne pas en oublier et vu comme je suis étourdi c'est pas du luxe.

De plus:
- le makefile me permet de lancer des script pour faire l'upload à ma TI ou à VTI(à l'époque ou j'arrivais à faire marcher le virtual link).

- il me permettait de faire différentes compilations, j'avais un "make core" qui ne construisait que tim_exe, tim_main et tim_api tandis que "make full" construit également les plugins et crée même la pack_archive.

Bref je dirais que le makefile est énormément plus souple mais bien évidement un peu moins évident. Sur la plupart des projets TI il sera dispensable.

Deux questions:

1- Comment crée-t-on un makefile?

2- Comment s'en sert-on?

Personnellement, je conseille d'utiliser exclusivement TIGCC IDE ou KTIGCC. La raison: ces EDIs mettent les switches que nous conseillons automatiquement pour les nouveaux projets, alors que la ligne de commande n'a pas de concept de "nouveau projet" (elle ne peut pas savoir si tu ne passes pas de switch parce que tu viens de créer le projet et as oublié de les mettre ou si c'est fait exprès parce que tu ne veux pas de ces switches), donc les réglages par défaut sont historiques (aucune optimisation , pratiquement pas de warnings ) et il y a 11 switches à mettre (-Os -ffunction-sections -fdata-sections --optimize-code --cut-ranges --reorder-sections --merge-constants --remove-unused -Wall -Wextra -Wwrite-strings, je conseille d'ailleurs de passer tous les switches à tigcc -c et tigcc, parce que certaines options d'optimisation linker nécessitent aussi d'assembler les fichiers différemment) pour avoir un programme optimisé convenablement et les warnings qu'il faut pour programmer proprement. De plus, TIGCC IDE ou KTIGCC offrent un comfort qu'aucune autre EDI ne peut donner (envoi automatique à TiEmu pour le débogage, par exemple).

KillerX (./4) :
1- Comment crée-t-on un makefile?
2- Comment s'en sert-on?

Il y a bien des outils automatiques mais je ne crois pas qu'ils soient vraiment adaptés pour TI.
Il faut créer un fichier Makefile à la main. Voici un petit exemple vraiment basique:

fichier_final: fichier_final.c fichier_final.h fichier_commun.h fichier_intermediaire.o
<tabulation>commande de compilation

fichier_intermediaire.o: fichier_intermediaire.c fichier_commun.h fichier_intermediaire.h
<tabulation>commande de compilation

Pour le lancer tu tapes "make" enventuellement suivi par le nom de l'entree que tu souhaite construire. Par défaut, il va essayer de construire la première entrée du fichier Makefile, en l'occurrence "fichier_final".
Pour cela il va vérifier la liste de ses dépendances fournies après le ":". Si le fichier à produire n'existe pas ou à une date de modification antérieure à ces dépendances, alors il est construit en utilisant la ligne de commande au dessous.
Comme le fichier intermediaire.o est défini plus bas dans le makefile il est lui aussi reconstruit si nécessaire.

sinon il y a pas mal de tutoriels disponibles sur le net, par exemple celui-ci

Ah c'est 'achement bien, après y'a surement des gens qui essaieront de te convertir aux autotools, mais perso j'en suis resté à make (même sous Windows, c'est dire ^^) et ça me convient tout à fait

Les autotools, c'est pas mal pour la sélection de configuration et la portabilité, mais la marche à l'entrée n'est pas forcément très petite à franchir...

Mais si tu veux vraiment un système de build pour lequel c'est ch*** de faire des build files, je te conseille d'essayer Maven
A travers son système de plugins, tu peux compiler un peu tout, quitte à faire ton propre plugin (en Java). C'est assez générique et puissant, mais plutôt lourd... et puis surtout, ça ne bouffe que des dizaines de lignes de XML pour les trucs les plus simples, des centaines quand on veut faire des trucs un peu complexes. Ca, c'est vraiment le pied

C'est nul les autotools, il faut utiliser CMake pour la vraie portabilité. En revanche, ni l'un ni l'autre ne sont adaptés au projets TI. Du tout.

En fait y'a quand même un truc sympa dans automake, c'est qu'il te cherche les dépendances tout seul.
Parce que maintenir soi même la liste des .h en dépendance des objets c'est super galère. Et si tu le fais pas, t'es obligé de faire un make clean à chaque modification de header.

autoconf... c'est bien pour les gros projets capables d'activer ou de désactiver des fonctionnalités selon les libs présentes sur le système. Faut en avoir l'utilité, sinon c'est juste un gros tas de bordel inutile.

Sauf que automake ne fonctionne pas sans autoconf.

Et CMake fait tout ça et plus (par exemple l'indication du pourcentage de complétion durant le make, même en couleurs) et est beaucoup plus simple à utiliser.

Qu'il faut compiler dès que tu n'est plus sur linux pour pouvoir l'utiliser.
Je préfère largement les autotools.

Euh, c'est disponible en binaires pour les OS non-libres les plus communs: http://www.cmake.org/HTML/Download.html. Quant aux OS libres, s'ils ne fournissent pas un paquetage ou un port/ebuild, ce n'est qu'à ton OS / ta distribution qu'il faut te prendre. Toutes les distributions GNU/Linux, *BSD etc. qui proposent KDE 4 proposent forcément aussi CMake parce qu'il le faut pour compiler KDE 4. Et il y a aussi les binaires GNU/Linux/i386 génériques.

Quant aux autotools, c'est la galère sur tout ce qui est non-*nix, tu te retrouves avec des trucs comme MSYS. Et même si tu restes dans du *nix, c'est une usine à gaz: par exemple, j'ai horreur de leur manière de recopier des informations dans chaque paquetage (donc si dans Fedora, on veut installer une lib ailleurs, par exemple pour éviter un conflit avec une autre lib, il faut patcher tous les logiciels qui utilisent celle lib ) alors que CMake centralise ça (donc un seul fichier à patcher, cf. par exemple http://cvs.fedoraproject.org/viewcvs/rpms/kdelibs/devel/kdelibs-3.95.0-parallel_devel.patch?rev=1.1&view=markup). Ce recopiage absurde de fichiers générés et de morceaux de fichiers ("snippets") gaspille aussi énormément de place, d'ailleurs. (Je pensais que tu étais contre le code recopié dans chaque application. )

Kevin Kofler (./16) :
: par exemple, j'ai horreur de leur manière de recopier des informations dans chaque paquetage (donc si dans Fedora, on veut installer une lib ailleurs, par exemple pour éviter un conflit avec une autre lib, il faut patcher tous les logiciels qui utilisent celle lib ) alors que CMake centralise ça (donc un seul fichier à patcher, cf. par exemple http://cvs.fedoraproject.org/viewcvs/rpms/kdelibs/devel/kdelibs-3.95.0-parallel_devel.patch?rev=1.1&view=markup ).

De quoi tu parles ?

Kevin Kofler (./14) :
Sauf que automake ne fonctionne pas sans autoconf.

Oui, ce qui est bien là le drame des autotools.

PpHd (./17) :
De quoi tu parles ?

Je parle:
* des fichiers comme missing, ltmain.sh etc. qui se retrouvent recopiés caractère pour caractère dans chaque programme,
* de l'horreur qu'est aclocal, qui a un fonctionnement absolument débile. Ça insère des morceaux de shell script dans configure, avec 2 processus possibles, créant chacun 2 (!) copies de ces morceaux par programme:
A. définitions "partagées":
1. aclocal recopie la définition présente sur le système sur lequel on le lance dans aclocal.m4 (une copie inutile),
2. autoconf recopie cette même définition dans configure (une deuxième);
B. acinclude.m4 (utilisé par KDE 3 par exemple):
1. le mainteneur recopie acinclude.m4 dans ses sources à la main (copie non seulement totalement inutile, mais en plus, ça marche bien si on n'en a qu'un seul, mais si chaque projet fait ça, il faut en plus concaténer tous ces fichiers acinclude.m4 ),
2. autoconf recopie cette définition dans configure (deuxième copie).

Avec CMake, c'est l'utilisateur (ou le packageur) qui lance cmake (et ça marche bien parce qu'ils ne font pas sans cesse des changements incompatibles comme les autotools ), donc le mainteneur ne doit pas recopier les snippets cmake déjà installés par les autres logiciels ou cmake lui-même (et une distribution peut facilement patcher ces fichiers parce qu'il n'y a qu'une copie). Et avant que tu te plaignes que ce n'est pas flexible, on peut aussi inclure ses propres snippets cmake (le fonctionnement prévu à la base pour acinclude.m4, mais ça a été souvent utilisé en pratique pour recopier des définitions dans chaque projet ), et ces snippets ne sont pas recopiés ailleurs dans le tarball (à la autoconf) non plus.

Et c'est tout ? Donc ca marche très bien