URL: https://linuxfr.org/users/mildred/journaux/une-alternative-%C3%A0-make1 Title: Une alternative à make(1) Authors: Mildred Date: 2009年07月22日T14:51:03+02:00 Tags: Score: 4 J'aimerais vous présenter un projet que je suis en train de développer, et qui est une nième alternative à la commande make que nous connaissons tous. Je l'ai nommé TBuild, le T étant là pour indiquer que j'utilise le langage [Tcl](http://fr.wikipedia.org/wiki/Tool_Command_Language). **Alors, qu'est-ce que je reproche à make ?** - il est trop rudimentaire (c'est la raison de vivre d'automake) - il est trop lié à la plateforme cible (on écrit des lignes de commande shell, et le shell, ça change pas mal selon la plateforme, de même, les options des compilateurs changent, on a créé autoconf et mingw pour ça) - il ne gère pas bien les fichiers avec des noms particuliers (avec des espaces surtout). Souvent, même, les alternatives à make ont les mêmes problèmes car elles fonctionnent (comme make) par remplacement de variables dans du code shell. Si j'écris par exemple: $(GENPDF) -o $@ $+ et que le fichier cible ($@) est par exemple mon joli document.pdf et que mon fichier source ($+) est ma jolie source.in, j'ai la ligne de commande suivante (par exemple): genpdf -o mon joli document.pdf ma jolie source.in Le shell va comprendre tout ça de travers et découper en mots selon les espaces. Si je met des guillemets dans ma commande, je pourrais m'en sortir jusqu'à ce que je rencontre un nom de fichier avec des guillemets ou une apostrophe. Pour le code source c'est rare, mais si on s'occupe de documents rédigés, ça peut arriver plus souvent. **Ce qui serait bien d'avoir :** - la puissance d'un langage de script complet pour pouvoir entre autre faire de la détection de plateforme au démarrage et adapter ce qu'on compile à l'environnement - une syntaxe proche du shell pour ne pas avoir à se baser sur l'interprétation de notre commande par un shell. Il s'agit de pouvoir faire un fork()+exec("gcc", "-o", ...) de la commande a exécuter directement plutôt que un appel de system("gcc -o ...") qui est interpréta par le shell. Et je n'ai rien trouvé. Donc, j'ai créé mon propre système. **TBuild** J'avais besoin d'un langage de programmation évolué proche de la syntaxe shell, le choix s'est donc naturellement porté vers [Tcl](http://fr.wikipedia.org/wiki/Tool_Command_Language) (je n'en connais pas d'autres avec ces caractéristiques). Après, je devais me décider sur une sémantique. Comment décrire avec Tcl les étapes de compilation ? Je me suis basée sur une alternative à make que je connaissait bien: [Jam](http://www.perforce.com/jam/jam.html). Voir un exemple de [TBuildfile.tcl](http://gitorious.org/tbuild/tbuild/blobs/master/src/TBuildfile.tcl) Pour le moment, les fonctionnalités restent très simples, et pas encore toutes testées. Il n'est pas encore possible de construire des fichiers en parallèle (mais c'est prévu). Il est aussi prévu que ce système soit sécurisé. C'est à dire qu'il serait possible de lancer tbuild sur un projet qu'on vient de télécharger et d'être sûr qu'il ne posera pas de problèmes. Tant que gcc n'a pas de failles de sécurité bien sûr :) L'idée est que le support des langages sur fait dans des packages (par exemple [le support du langage C](http://gitorious.org/tbuild/tbuild/blobs/master/tcl.pkg/Clang.tcl)). Ces packages seraient préinstallés, et sont a priori sécurisés (Clang ne pourra par exemple que lancer gcc sur des fichiers ne sortant pas du répertoire source). Il sera possible d'importer un package non sécurisé, mais l'utilisateur sera averti et aura la possibilité d'annuler l'opération. Voir le code: [http://gitorious.org/tbuild/tbuild](http://gitorious.org/tbuild/tbuild)