Pensando a una lingua per le definizioni di costruzione

1

Voglio scrivere un piccolo strumento che analizza le definizioni di build e le converte in un file ninja.build . Non dovrebbe compilare compilation come CMake o Meson, ma essere simile a make in che tu scrivi manualmente i comandi per un passo di costruzione.

Ho costruito una soluzione quasi funzionante in Python, ma ci sono alcune pietre miliari che non sono stato in grado di risolvere facilmente e il design non è l'ideale. Il mio obiettivo principale è avere definizioni di compilazione modulari ed essere in grado di modificare queste definizioni da un altro progetto per i suoi requisiti. Immaginate

use platform
use platform.compiler as compiler

# Another user created build definition file.
use foolib

build_dir : join(project_path, 'build')
foolib.build_dir : build_dir  # Here we change the build_dir of the library
foolib.defines : array(foolib.defines, 'FOOLIB_LEGACY_API')  # And here we add another define

sources : wildcard('source/*.cpp')
objects : transform(sources, 'source', join(build_dir, 'obj'), platform.objsuffix)
executable : join(build_dir, platform.exename('main'))
includes : array(localpath('include'), foolib.includes)
defines : array(foolib.defines, 'BUFSIZE=512')
flags : compiler.includes(includes) compiler.defines(defines)

# Automatically deduces to issue a command for each source/object pair
target sources -> objects  
    compiler.cpp quote(input) flags compiler.compile_only compiler.out(output)

target array(objects, foolib.library) -> executable
    compiler.cpp quote(input) flags compiler.out(executable)

foolib sembrerebbe abbastanza simile, con l'output di un file di libreria dai file sorgente al suo build_dir .

Uso sempre l'espansione delle variabili pigro in ogni momento per consentire cose come cambiare la directory di costruzione di un progetto importato o aggiornare le definizioni di macro utilizzate durante la compilazione della dipendenza.

Il problema che ho con la valutazione lazy è con auto-referenze, e aggiunge anche un sacco di overhead. Tuttavia, fare una valutazione immediata sull'assegnazione non consentirà questo ritardo nel cambio di configurazione.

Un altro aspetto è che voglio essere in grado di specificare le opzioni sulla riga di comando che avranno effetto sulla configurazione dei moduli. Ad esempio, supponiamo di voler creare il mio programma in modalità di debug.

if debug == 'true'
    executable : join(build_dir, platform.exename('main-dbg'))
    flags : flags compiler.debug
    defines : array(defines, 'DEBUG')

Se foolib utilizza lo stesso condizionale per aggiornare i flag di compilazione e definisce, sarà anche costruito in modalità di debug. Anche se in questo caso speciale, sarebbe auspicabile, potrebbe esserci un caso in cui voglio essere specifico per renderlo impostato solo per il mio programma ma non per il modulo foolib .

Hai idee per miglioramenti, un design diverso o migliore?

    
posta Niklas Rosenstein 02.02.2015 - 22:24
fonte

1 risposta

1

Probabilmente è una buona idea leggere il link (altre distribuzioni Linux probabilmente avranno qualcosa di simile). Rispettare le variabili di ambiente (ad esempio CFLAGS) è importante (vedere la discussione di SCons e waf per i problemi creati non facendo ciò).

    
risposta data 05.02.2015 - 01:13
fonte

Leggi altre domande sui tag