Perché gli strumenti di compilazione utilizzano un linguaggio di scripting diverso dal linguaggio di programmazione sottostante?

La scelta di quale linguaggio di programmazione utilizzare per ottenere qualcosa deve dipendere dalle caratteristiche specifiche di quell'obiettivo e non dalle altre attività correlate a quel progetto.

Uno strumento di compilazione esegue un lavoro molto specifico e indipendentemente dalla lingua utilizzata per il progetto principale, uno strumento di compilazione è un software di per sé.

Cercare di legare il progetto principale e il suo strumento di costruzione potrebbe essere una pessima decisione. Quello di cui si dovrebbe avere bisogno con uno strumento di compilazione è principalmente un rapido processo di regole semplici, con una veloce gestione di file e IO.

Se linguaggi come il ruby si usano per implementare il loro strumento di costruzione, sono legati più alle caratteristiche di quella lingua che alla presunta necessità di mantenere tutto scritto con la stessa lingua.

Non è impossibile scrivere uno strumento di compilazione che utilizza un linguaggio come C o Java come linguaggio di scripting. Tuttavia, gli strumenti di sviluppo traggono vantaggio dall'utilizzo di più linguaggi di scripting dichiarativi . Immagina il dolore e lo schema di scrittura di un makefile (o build.xml, o qualsiasi altra cosa) in C.

Gli strumenti di sviluppo traggono vantaggio dall'uso di DSL, un'attività per la quale C non rappresenta una scelta particolarmente valida. C è troppo generico per uno strumento di compilazione e troppo interessato a errori & dettagli di basso livello. Ad esempio, non si vuole preoccuparsi della gestione della memoria esplicita in uno strumento di compilazione! Quindi, anche se usi la sintassi di tipo C, probabilmente utilizzerai la garbage collection nel tuo strumento di scripting, a questo punto perché non usare semplicemente un DSL dedicato?

È logico utilizzare Ruby per questo, poiché è un linguaggio di livello superiore e più dichiarativo di C o Java. Vedi anche: Gradle, sbt.

Diamo un esempio realistico.

Circa 15 anni fa ho lavorato al porting di un grande sistema scritto in C da Unix a Windows, si trattava di circa 3 milioni di righe di codice. Per darti un'idea della scala, ci sono voluti più di 24 ore per compilare alcuni dei nostri sistemi unix (RS6000), Windows poteva compilare il sistema in circa 4 ore.

(Avevamo anche 2 milioni di righe di codice nel nostro linguaggio interpretato, ma abbiamo deciso di non usare il nostro linguaggio per i sistemi di compilazione in quanto non era mai stato progettato per l'elaborazione dei file. Inoltre avevamo bisogno di un sistema di compilazione per compilare il codice C che implementato la nostra lingua.)

Nel momento in cui il sistema di compilazione è stato scritto in un mix di script di shell e crea file, questi non erano portabili a Windows - quindi abbiamo deciso di scrivere il nostro sistema di compilazione.

Avremmo potuto usare C, tuttavia abbiamo deciso di usare python, c'erano pochi motivi. (Abbiamo anche riscritto il nostro sistema di controllo del codice sorgente in Python allo stesso tempo, questo è stato molto intergradato con il sistema di compilazione, quindi i file oggetto per i moduli archiviati potrebbero essere condivisi dagli sviluppatori.)

• La maggior parte del nostro codice potrebbe essere costruita con poche semplici regole (solo poche migliaia di righe di python per tutte le piattaforme, Windows, VMS e 6 versioni di Unix) che sono state ricavate dalle convenzioni di denominazione dei file .

• Al momento RegEx non era molto standard tra i sistemi C su piattaforme diverse, Python aveva costruito in RegEx.

• Alcuni moduli richiedevano passaggi di compilazione personalizzati, i file di classe consentiti da Python venivano caricati dinamicamente. Abbiamo permesso a una classe personalizzata di essere usata per costruire un modulo (lib), basato sul fatto che il file python avesse un nome magico nella cartella. Questo era il motivo killer per usare python.

• Abbiamo preso in considerazione Java, ma a quel punto non era disponibile su tutte le piattaforme.

(L'interfaccia utente per il nostro sistema di controllo del codice sorgente utilizzava un browser web che era portatile su tutta la piattaforma, 6 mesi prima che avessimo una connessione Internet. Dovevamo scaricare il browser su X25!)

La risposta breve a questa domanda è che questo è ciò che uno strumento di costruzione è . Uno strumento che automatizza l'utilizzo di altri strumenti, con l'obiettivo di creare un prodotto finale da alcuni file sorgente. Se stiamo scrivendo lo script di compilazione nella stessa lingua del prodotto stesso, siamo nei regni degli strumenti specifici della lingua, che non sarebbero considerati strumenti di creazione nello stesso modo.

Ciò solleva la domanda: perché i compilatori non forniscono il tipo di automazione di creazione a cui siamo abituati da strumenti come make? A cui la risposta è semplicemente perché make esiste . La filosofia Unix di "fare una cosa e farla bene" suggerisce che non è responsabilità del compilatore fornire questo *. Detto questo, sono stato personalmente attraverso la mia parte di creare mal di testa e sarei interessato a provare un compilatore che fornisce il proprio sistema di compilazione "nativo" preventivo.

Per un esempio di un compilatore progettato in questo modo, vedi Jon Blow (non ancora pubblicato) Jai, un linguaggio inteso come una sostituzione C ++. I link a discussioni e demo del compilatore sono raccolti qui . Questo linguaggio compila il codice byte che viene eseguito all'interno del compilatore, con la compilazione in binario essendo una funzione fornita da una libreria standard, accessibile dal codice byte. L'intenzione è di consentire sia l'automazione di build che la meta-programmazione all'interno della sintassi nativa del linguaggio.

_{* Uno sguardo a Visual Studio di Microsoft ti mostrerà un esempio della filosofia opposta. :)}

Lo strumento di creazione è innanzitutto uno strumento, proprio come 'gcc', 'ls', 'awk' o 'git'. Si alimenta lo strumento con un input (nomefile, parametri, ecc.) E farà alcune cose di conseguenza.

Tutti questi strumenti ti consentono di inserire i tuoi input in modi che dovrebbero essere abbastanza semplici da scrivere e capire. Nel caso particolare degli strumenti di compilazione, l'input è un file di ricette, un file che descrive come il tuo progetto va dai file di origine al prodotto finito.

Se la tua ricetta è semplice come passare nella cartella che contiene il progetto e il compilatore da usare, allora è sufficiente una "lingua" dichiarativa. Una volta che la ricetta diventa sempre più complicata, con più logica, diventa difficile gestirla con linguaggi dichiarativi e vengono utilizzate linguaggi più generici.

Ora dovrebbe essere evidente che non esiste alcuna connessione tra il linguaggio utilizzato per scrivere le ricette di compilazione e le lingue utilizzate per scrivere il codice del prodotto semplicemente perché hanno scopi e requisiti diversi. Non c'è nessuna connessione tra la lingua in cui è scritto lo strumento di costruzione e la "lingua" in cui devono essere scritte le ricette di costruzione. Usa sempre lo strumento migliore per il lavoro!