Un employé de Red Hat a présenté le système de construction Goals. Sortie de GNU Make 4.2

Richard Jones, auteur libguestfs, travaillant chez Red Hat, présenté un nouvel utilitaire de construction Objectifs, visant à corriger les défauts et problèmes de l'outil make tout en préservant la simplicité et la clarté des scripts. L'outil make a été conçu en 1976 et présente plusieurs défauts conceptuels, qui seront corrigés dans Goals sans changer la conception globale.
Code source de Goals est distribué sous licence GPLv2+.

Problèmes résolus:

• Support d'une seule tactique de résolution des dépendances — « l'instruction de construction s'exécute si le fichier cible est absent ou plus ancien que l'une des dépendances ». Goals prévoit d'implémenter d'autres tactiques, telles que la vérification d'URL, la comparaison des dates de modification avec tout fichier, l'évaluation de la construction du paquet dans Koji, la comparaison des sommes de contrôle, l'exécution des ensembles de tests avec des passes sélectives.
• Lors du traitement des objectifs de construction, l'outil make ne distingue pas les fichiers des noms de règles et, en conséquence, il n'y a pas de vérification que lors de l'exécution d'une règle, le fichier dont la création est annoncée sera effectivement généré. Par exemple, si un fichier nommé « test » est accidentellement créé alors qu'une règle nommée « test » exécute des scripts de test, les tests cesseront d'être appelés, car make considérera que l'objectif est atteint et ne nécessite aucune action (pour contourner le problème dans make, on peut utiliser la directive « .PHONY: test »). Goals sépare clairement les fichiers des noms de règles.
  
• Problème de n'avoir qu'un seul paramètre pour les instructions de construction.
  

  Goals propose d'utiliser un nombre arbitraire de paramètres nommés. Par exemple, il est possible de séparer un attribut du nom indiquant un fichier de débogage :

  
• Problèmes d'interaction avec l'interpréteur shell. Par exemple, la nécessité de contrôler l'échappement des espaces dans les noms de fichiers et de répertoires, le gaspillage de ressources à lancer un interpréteur shell séparé pour chaque commande, la double interprétation du symbole « $ » (utilisé à la fois dans le shell et dans make), la prise en compte des indentations.

  Les problèmes mentionnés sont résolus dans Goals en utilisant le symbole « % » au lieu de « $ » pour les variables de construction (le « $ » reste uniquement pour le shell), en appliquant un parseur LALR(1), nécessitant d'encadrer les chemins et les noms de fichiers entre guillemets et de délimiter les blocs de code entre accolades. Tout le bloc s'exécute dans une seule instance de shell, et un formatage de code aléatoire est autorisé à l'intérieur du bloc, sans attacher à des espaces spéciaux.

  Avant :
  cible: foo.o bar.o
  ${CC} ${CFLAGS} $< -o $@

  Devenu:
  «cible»: «foo.o», «bar.o» {
  LAGS < -o %@
  }

Autres caractéristiques de Goals :

• Support optionnel pour la définition de noms et de paramètres arbitraires :

  objectif all = : «cible»

  objectif lien =
  «cible» : «foo.o», «bar.o» { … }

  objectif compilation (nom) =
  «%name.o» : «%name.c», «dep.h» { LAGS -c $^ -o $@ }

• Deux modes d'exécution : le mode make pour faire correspondre les objectifs de construction aux noms de fichiers (par exemple, le fichier «foo.o» correspond à l'objectif «%name.o»), et le mode d'exécution directe de la compilation :

  objectif all = : lien

  objectif lien =
  «cible» : «foo.o», compilation («bar») { … }

  objectif compilation (nom) =
  «%name.o» : «%name.c», «dep.h» { LAGS -c $^ -o $@ }

• La tactique de construction est déterminée par des règles spéciales, permettant de définir si une reconstruction de l'objectif de construction est nécessaire. Si une liaison à l'existence d'un fichier est effectuée, cela est clairement défini par le signe correspondant («cible» pour le nom de la règle et *file(«cible») pour vérifier l'existence du fichier).

  «cible» : «foo.o», «bar.o» { … }

  *file(«cible») : *file(«foo.o»), *file(«bar.o») { … }

• Le développeur peut définir des signes arbitraires dans les tactiques de construction. Le signe «*file» est défini par défaut (@{…} indique la suppression de la sortie, et «exit 99» signale qu'une reconstruction est nécessaire) :

  tactique *file (nom_fichier) = @{
  test -f %filename || exit 99
  pour f dans %

  Source : opennet.ru