Un dipendente di Red Hat ha presentato il sistema di build Goals. Uscita di GNU Make 4.2

Richard Jones (Richard WM Jones), autore libguestfs, che lavora presso Red Hat, ha presentato un nuovo strumento di build Goals, mirato a correggere le carenze e i problemi dello strumento make mantenendo la semplicità e la comprensibilità generale degli script. Lo strumento make è stato progettato nel 1976 e presenta diverse carenze concettuali, che nel Goals si prevede di correggere senza cambiare la concezione generale.
Codice sorgente di Goals è distribuito con licenza GPLv2+.

Problemi affrontati:

  • Supporto per una sola tattica di risoluzione delle dipendenze — "l'istruzione di build viene eseguita se il file di destinazione è mancante o se è più vecchio di una delle dipendenze". In Goals si prevede di implementare anche altre tattiche, come il controllo della disponibilità di URL, il confronto dei tempi di modifica con qualsiasi file, la valutazione della costruzione del pacchetto in Koji, il confronto delle checksum, l'esecuzione di set di test con esclusione selettiva dei test.
  • Nell'elaborazione degli obiettivi di build, lo strumento make non distingue tra file e nomi delle regole e, di conseguenza, non verifica se al momento dell'esecuzione della regola verrà effettivamente creato il file proclamato. Ad esempio, se esiste una regola con il nome "test" che esegue script con test, e per caso viene creato un file di nome "test", i test smetteranno di essere eseguiti, poiché make considererà che l'obiettivo sia stato raggiunto e non richieda ulteriori azioni (per aggirare il problema in make si può utilizzare la direttiva ".PHONY: test"). Goals distingue chiaramente tra file e nomi delle regole.

    Un dipendente di Red Hat ha presentato il sistema di build Goals. Uscita di GNU Make 4.2
  • Problema di fornire un solo parametro per le istruzioni di build.

    Un dipendente di Red Hat ha presentato il sistema di build Goals. Uscita di GNU Make 4.2

    In Goals si propone di utilizzare un numero arbitrario di parametri nominati. Ad esempio, è possibile estrarre separatamente dal nome un indicatore del file di debug:

    Un dipendente di Red Hat ha presentato il sistema di build Goals. Uscita di GNU Make 4.2
  • Problemi di interazione con l'interprete shell. Ad esempio, la necessità di controllare l'escape degli spazi nei nomi di file e directory, il consumo di risorse per avviare un singolo interprete shell per l'esecuzione di ogni comando, la doppia interpretazione del simbolo "$" (utilizzato sia nella shell che in make), il rispetto degli spazi.

    I problemi sopra menzionati sono risolti in Goals utilizzando il simbolo "%" al posto di "$" per le variabili di build ("$" rimane solo per la shell), applicando un parser LALR(1), che richiede di racchiudere i percorsi e i nomi dei file tra virgolette e di racchiudere tra parentesi graffe i blocchi di codice. L'intero blocco viene eseguito in un'unica istanza della shell dei comandi, e all'interno del blocco è consentito un formattazione arbitraria del codice, senza vincoli su spazi speciali.

    Era:
    target: foo.o bar.o
    ${CC} ${CFLAGS} $< -o $@

    Diventato:
    «target»: «foo.o», «bar.o» {
    LAGS < -o %@
    }

Altre caratteristiche dei Goals:

  • Supporto opzionale per la definizione di nomi e parametri arbitrari:

    goal all = : «target»

    goal link =
    «target» : «foo.o», «bar.o» { … }

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

  • Due modalità di esecuzione: modalità make per associare gli obiettivi di costruzione ai nomi dei file (ad esempio, il file «foo.o» corrisponde all'obiettivo «%name.o»), e modalità di avvio diretto della compilazione:

    goal all = : link

    goal link =
    «target» : «foo.o», compile («bar») { … }

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

  • La tattica di compilazione è definita da regole speciali, attraverso le quali è possibile determinare la necessità di ricostruire un obiettivo di costruzione. Se è vincolata all'esistenza di un file, ciò è esplicitamente definito tramite il relativo indicatore («target» per il nome della regola e *file(«target») per il controllo del file).

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

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

  • Lo sviluppatore può definire indicatori arbitrari per le tattiche di costruzione. L'indicatore «*file» è definito per impostazione predefinita (@{…} indica il silenziamento dell'output e «exit 99» segnala la necessità di ricostruzione):

    tactic *file (filename) = @{
    test -f %filename || exit 99
    for f in %

    Fonte: opennet.ru

Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server 🔥 Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server | ProHoster