Esistono validi strumenti di gestione delle dipendenze che non sono specifici della lingua?

Question

Sto cercando uno strumento di gestione delle dipendenze che non sia specifico di Java o di qualsiasi altra lingua.

Utilizziamo SystemVerilog, un linguaggio di descrizione dell'hardware, per creare moduli standalone. Tagghiamo i rilasci di quei moduli a varie tappe. I disegni di livello superiore spesso inseriscono altri moduli usando i tag Subversion.

Abbiamo tentato di utilizzare Subversion esterni per automatizzare le cose, in modo che quando si estrae un modulo si ottengano anche le sue dipendenze. Ma quando arrivi al livello di sistema, ci sono così tanti elementi esterni nidificati che impiega un'ora per eseguire svn update. Chiaramente quell'approccio non funziona.

Fondamentalmente, voglio essere in grado di dire, "Il mio modulo dipende da questa versione del modulo A, da questa versione del modulo B e da questa versione del modulo C." Lo strumento eseguirà il lavoro di verifica delle dipendenze, verificando le dipendenze delle dipendenze e assicurandosi che non vi siano dipendenze in conflitto (ad esempio, due versioni dello stesso modulo).

Esistono strumenti che funzionano bene con una lingua arbitraria e Subversion?

Answer 1

Non sento il dolore del rilevamento delle dipendenze che stai descrivendo, il che significa che probabilmente non capisco del tutto il tuo problema.

Un approccio consiste nel mantenere tutte le versioni di moduli in file separati nella stessa libreria. Ad esempio, è possibile avere adder_0_0.sv per la prima versione di un modulo HDL full adder, che descrive un modulo chiamato adder_0. Se trovi un errore nel modulo, puoi creare un file chiamato adder_0_1.sv che descrive anche adder_0. Sarai in grado di utilizzare adder_0_1.sv anziché adder_0_0.sv. Se si desidera modificare l'interfaccia, aggiungendo o rimuovendo le porte o modificando la semantica delle porte, è possibile creare un file denominato adder_1_0.sv che descrive un modulo denominato adder_1. Si noti che adder_0 e adder_1non possono essere utilizzati in modo intercambiabile.

La filosofia alla base di questo approccio è che tutti questi file sono scrivere una volta. Continui ad aggiungere nuovi file alla tua libreria. Qualsiasi progetto che utilizza questa libreria controlla l'intera libreria e utilizza i file desiderati. La gestione delle dipendenze è tanto complicata quanto inserire i nomi file giusti nel file di descrizione del progetto giusto per qualsiasi strumento di simulazione o sintesi che si usa. Non è richiesto uno speciale strumento di gestione delle dipendenze. Meno librerie separate hai, più facile sarà gestirle.

Answer 2

Una volta ho avuto un flusso di strumenti che cercava i file di origine in due punti. Per prima cosa, è apparso nella directory locale. In secondo luogo, sembrava nell'area "principale" che era condivisa, directory di sola lettura con tutto il codice estratto per tutti da usare. Se dovevo modificare il codice, ho solo controllato il modulo di cui avevo bisogno. Quindi, lo script avrebbe preso quel modulo dal mio spazio di lavoro locale. Il resto del codice che ha letto dall'area principale. Questo era tutto uno scripting personalizzato, non uno strumento da scaffale, ma non era troppo difficile.

Se si ottiene questo funzionamento, è possibile andare oltre e compilare il codice area principale in librerie master condivise. Questo potrebbe davvero accelerare il tempo di compilazione.