Qualcuno può raccomandare un modo agnostico per la toolchain di dichiarare e documentare le dipendenze di compilazione dei pacchetti?

2

Attualmente ho un progetto in mano che lascerò presto (lavoro di dottorato) e che dovrebbe essere lasciato in una forma comprensibile dal momento che è probabile che venga ripreso, anche se non è ancora noto da chi e quando.

Pertanto, mi piacerebbe lasciare almeno un po 'di documentazione su come è costruita. Il progetto consiste di 7 pacchetti, ognuno dei quali è un pacchetto di codice sorgente indipendente la cui compilazione dipende solo da librerie e intestazioni da altri pacchetti. L'intero processo di costruzione ruota attorno agli standard open source, cioè ogni progetto è creato da autoconf e automake, è Debianizzato e le dipendenze tra pacchetti sono dichiarate nei pacchetti Debian e controllate negli script di configurazione.

Tuttavia, questo sembra un modo abbastanza specifico di specificare un problema abbastanza generale. È probabile che il prossimo manutentore voglia creare il software con una GUI di Windows che non sappia nulla di autoconf o Debian. Mi piacerebbe lasciare una documentazione più rigida in questo caso rispetto a una serie di commenti nei vari file INSTALL e nelle dichiarazioni Build-Depends / Depends nei file Debian.

Esiste un linguaggio o uno standard agnostico basato su toolchain per documentare l'imballaggio e creare l'ordine? Punti bonus se le specifiche del sistema di costruzione reale (come Debian Build-Depends) potrebbero essere generate da questo.

    
posta thiton 04.10.2011 - 13:13
fonte

1 risposta

1

Graphviz è altamente leggibile e modificabile oltre allo scopo di generare output grafico per la documentazione. In un paio di progetti diversi nel corso di molti anni, ho scritto alcuni semplici strumenti che hanno generato l'output di graphviz o semplicemente digitato manualmente i dep. Il risultato è che i project manager e i capi hanno stampato tutte le copie e le hanno registrate sulle loro lavagne perché hanno trovato i diagrammi così utili.

Uno di questi era per l'intera catena di dipendenze per un grande progetto di sistemi embedded gnu / linux, e c'erano dozzine di dipendenze tra toolchain, binutils, pacchetti gpl, ecc. ecc. ecc. Il diagramma diventava troppo grande per adattarsi carta di dimensioni legali.

(Tangenzialmente: questo è l'enorme costo nascosto di scegliere gnu / linux: dozzine di pacchetti indipendenti da autori che non integrano i loro pacchetti l'uno con l'altro. Se fosse netbsd, il "sistema" sarebbe solo un prodotto da un fornitore: la versione netbsd.)

    
risposta data 04.10.2011 - 23:58
fonte

Leggi altre domande sui tag