Come generare il codice generato dalla versione senza controllarli in VC?

Question

Come generare il codice generato dalla versione senza controllarli in VC?

#1 da (4 voti)
#2 da (4 voti)
#3 da (1 voti)

1

Ho scritto un generatore di codice per la mia azienda, che fondamentalmente ha il seguente flusso di lavoro:

                 entity xml definition  
                         |
                         v
   gets validated and put into java runtime classes by jaxb
                         |
                         v
runtime classes are written to .java files with stringtemplate

Ora è possibile avviare un server e usare quei file. Fin qui, tutto bene.

Prima di poter installare il server per i nostri clienti, è necessario che sia convalidato per GAMP 5, operazione che richiede molto lavoro. Ogni volta che c'è una modifica al sistema, dobbiamo provare TUTTO da zero, se non possiamo esserne sicuri, che non è cambiato.

Pertanto, ho bisogno di avere un concetto su come eseguire la versione del codice generato.

Il problema (1) è che il codice generato è né commited to git, né a SVN ; solo le definizioni xml sono inserite in SVN.

Un'altra cosa (2) è che una volta che il compito gradle per generare il codice, che è necessario non appena qualcosa è cambiato nei file xml, (al momento) rigenera TUTTI i file .java , anche se non è stata apportata alcuna modifica al file xml della rispettiva entità.

La terza (3) cosa da avere in mente è che un'entità può essere estesa da un altro file xml. il flusso di lavoro per questo sarebbe simile a

                 entity xml definition  extension xml definition
                         |                         |
                         v                         v
   gets validated and put into java runtime classes by jaxb
                         \                        /
                          \                      /
                     Merging the runtime classes together
                                     |
                                     v
      runtime classes are written to .java files with stringtemplate

Un'idea

doveva generare il file .java e prima di sovrascrivere i vecchi file, leggerli e sovrascriverli solo se differiscono. Il messaggio di output direbbe quindi quali parti del software devono essere riconvalidate

Un altro approccio includerebbe la generazione di hashcode per tutti i file e vedere se questi differiscono dagli hash precedenti.

Quale sarebbe il modo migliore per farlo?

code-generation versioning

posta Do Re 01.03.2017 - 08:37

fonte

3 risposte

4

Come ho commentato, suggerirei di controllare la versione dei file generati.

Li inserirai in una sottodirectory (controllata dalla versione), forse generated/

Aggiungerai file in generated/ solo dopo aver verificato che il contenuto del file generato sia effettivamente cambiato (il suo timestamp non è sufficiente).

È una cosa comune per molti compilatori bootstrap (che versione controlla alcuni moduli "compilati", ad es. essere in grado di compilare se stessi), tra cui Ocaml in boot/ocamlc , il mio GCC MELT (quale versione controlla codice C ++ generato in generated/ ) , Bigloo , Schema di pollo

^{(un'eccezione interessante è Rust: non distribuisce il compilatore Rust eseguibile, ma lo script di installazione è recupero -usando wget o curl comando- che è eseguibile da un URL remoto canonico)}

È necessario scrivere script specifici per installare i file generati nella sottodirectory controllata dalla versione.

Potresti voler usare ganci del tuo sistema VC, ad es. git ganci se si utilizza git (o forse svn hook per svn , ma vi lascio controllare, non li ho mai usati)

Probabilmente dovresti occuparti di quando inserisci effettivamente nuove versioni dei tuoi file generati nella sottodirectory generated/ . Fai attenzione quando fai questo (probabilmente non vuoi farlo troppo spesso, per evitare inutili commit, ma sicuramente vuoi eseguire molti test prima di commetterlo).

risposta data 01.03.2017 - 10:49

fonte

1

Abbiamo avuto un'opportunità totalmente diversa:

Invece di fare il versioning del codice generato, faremo la versione dell'intero buildsystem e dei file xml.

In questo modo, possiamo dire con certezza, con quale versione del generatore è stato generato il codice e quale versione dei file xml è stata utilizzata.

Inoltre, non abbiamo bisogno di memorizzare tutto il codice generato nei sistemi di controllo della versione.

risposta data 03.03.2017 - 10:05

fonte

Leggi altre domande sui tag code-generation versioning

Denominazione: objectAction o actionObject? [chiuso] TDD e in attesa di dipendenze

score 4 · Accepted Answer

Generalmente è considerata una cattiva idea per i file generati dal controllo della versione. Il problema è che probabilmente hai già i file di generazione memorizzati nel sistema di controllo della versione. Quindi hai essenzialmente le stesse informazioni due volte. Inoltre, qualcuno può dimenticarsi accidentalmente di aggiornare i file generati dopo aver aggiornato i file generati.

Hai considerato un sistema di generazione intelligente che genera automaticamente i file generati? Se gli strumenti modificano sempre il timestamp di tutti i file generati nonostante non possano essere modificati, la soluzione è di confrontare il contenuto dei nuovi file con il contenuto dei vecchi file e aggiornarli se differiscono. Non usare solo il codice hash, è troppo rischioso. I codici hash sono pensati per le tabelle hash e in questo caso ci saranno collisioni. Invece, utilizzare un hash sicuro come SHA256 (SHA1 è già rotto e MD5 è stato interrotto per un lungo periodo di tempo). Oppure puoi fare un confronto completo dei file invece di un hash sicuro.

In alternativa, puoi aggiornare gli strumenti anziché eseguire gli hack per impedire modifiche nel tuo sistema di generazione.

Comunque, dal momento che stai usando Java, la compilazione sarà veloce anche se tutto deve essere ricompilato. Il mio progetto attuale usa C e la compilazione completa richiede alcuni minuti (un file C con dieci righe contenente pochi #include può finire per essere analizzato come un file C da 10.000 fogli ...).