ElectroYou

Ciao a tutti

Come ormai sapete lavoro in un gruppo e non sempre siamo dello stesso parere.
Capita quindi che mi interessa sapere il vostro parere a fini statistici (sono io ad essere fuori dal mondo o sono i miei colleghi che non capiscono una mazza? ).

Oggi parliamo di codice sorgente generato automaticamente.
Per farla breve, in un progetto abbiamo bisogno di parecchio codice sempre uguale a parte nome e un paio di dettagli per ogni istanza di una certa "roba".
Abbiamo deciso di descrivere nome e dettagli in un file CSV, c'è poi uno script Python che legge il file CSV e genera una miriade di files C++.

La domanda è se versionare i file C++ o meno.

Questo è un possibile scenario:
- lo script in python è versionato, così come il file CSV
- lo script in python viene chiamato dall'IDE nei pre-build events
- i file C++ generati non sono versionati

Oppure:
- lo script in python è versionato, così come il file CSV
- lo script viene chiamato manualmente da chi modifica il file CSV
- i file C++ generati vengono aggiunti al version control
- l'IDE non genera niente autonomamente

Sono concepibili anche altre soluzioni (per esempio che la generazione avvenga solo sul continuous integration server e poi inseriti nel version control), ma è roba veramente astrusa.

Voi come agireste?

Al solito, non vi dico cosa penso io per non influenzarvi

Boiler

Sarei curioso di avere qualche dettaglio in più sul progetto (che si possa rendere pubblico, ma che rimanga anonimo).
Non capisco perché generare del codice sorgente tutto uguale automaticamente, cioè (magari non è così), che forse si potrebbe organizzare meglio il progetto lato firmware (se stiamo parlando di un firmware).

Comunque secondo me non ha senso mettere sotto versione roba che viene prodotta dal build, come non metteresti sotto versione i binari.
Non so se abbiate un male o una cosa simile che automatizza il build, comunque versionerei solo ciò che non viene generato, quindi script python, file CSV, eventualmente il template c++ se non è integrato nel file python.

Però ecco la necessità di codice sempre uguale mi fa accendere un campanello di allarme di qualcosa che si potrebbe fare diversamente proprio dall'inizio.

Secondo me i file generati vanno versionati, ma in un repository separato e solo per un branch specifico del generatore. Questo perché ovviamente si vuole tenere traccia dei cambiamenti sul generatore, ma per coloro che usano il codice finale C++, o devono integrarlo, ciò che conta è semplicemente quello. Oltre a questo aspetto, possono esserci sorgenti in C++ non sottoposti ad autogenerazione, ma che è comunque importante tracciare e parte del progetto. Magari non oggi, ma in 2 mesi compare questa necessità e non ha senso dover ridisegnare la pipeline di versioning solo perché si sono seguite scorciatorie ora :).

In questo modo, con un versioning esplicito è anche possibile comprendere più facilmente se vi sono state regressioni nella qualità del codice generato.

Se il codice C++ generato non verrà mai usato esternamente al progetto e condiviso con altri, fatto salvo i vantaggi dell'ultimo punto la mia propensione per il loro versioning è meno sviluppata .

Se il codice generato non verrà mai editato e ricompilato perché non sono necessarie operazioni di "fine tuning" del progetto non ha senso inserirlo in un repository di controllo versioni. Otterreste n progetti tutti uguali alimentati solo dal generatore di codice.
L'unica cosa che mi viene in mente in cui potrebbe avere una qualche utilità, in ambiente di produzione, potrebbe essere quello di tornare velocemente ad una versione precedente, ma anche qui spesso si rende necessario un processo di pulizia di file temporanei o sul db per cui non sarebbe nemmeno così tutto questo gran risparmio di tempo.

Sono contrario a mettere codice generato automaticamente in un repository con un version control system (non posso usare il verbo versionare, al massimo controllo versione), genera solo problemi, nel repository deve finire solo il codice che genera il software niente file intermedi auto-generati e neanche i binari.

Il problema è come quel codice verrà usato in ambito operativo. La mia ipotesi è che a seguito della generazione automatica sia adottato da decine di persone all'interno di un progetto più complesso (o più progetti) in forma di submodule per esempio. A quel punto hai due strategie:
- O offri il sorgente generato con possibili patch in un repository separato.
- Pretendi che ciascuno degli sviluppatori debba farsi carico in locale della generazione (per carità automatica) del sorgente in esame. Integrando il task in cmake o qualcosa del genere.
Python non è un linguaggio veloce, e le dipendenze per la generazione del codice possono essere significative. A quel punto vuol dire che ogni sviluppatore, che python magari non vuole nemmeno toccarlo, è costretto a gestire in locale una sua distribuzione aggiornata con tutte le librerie rilevanti. Solo per poter usare del codice C++.

A livello di energia spesa, compreso il costo umano di gestire una soluzione che scala O(n) in base al numero di sviluppatori coinvolti, credo che la prima opzione sia più razionale anche se apparentemente ridondante.
Senza contare la possiblità di evidenziare in modo più chiaro regressioni nel codice visto che non è detto siano immediatamente evidenti dal "sorgente" csv ed il compilatore.

Grazie a tutti per le risposte finora date. Mi piace lasciar correre la discussione senza in influenzarla per un certo periodo di tempo, ma ora vi devo un paio di risposte e precisazioni

drGremi ha scritto:Sarei curioso di avere qualche dettaglio in più sul progetto (che si possa rendere pubblico, ma che rimanga anonimo).
Non capisco perché generare del codice sorgente tutto uguale automaticamente, cioè (magari non è così), che forse si potrebbe organizzare meglio il progetto lato firmware (se stiamo parlando di un firmware).

Esempio banale: il memory management delle variabili coinvolte in un progetto embedded. C'è un'entità che si occupa di gestire le variabili che sono "globali" (insomma, a cui accedono piú moduli).
Per ognuna di queste variabili va generato un getter e un setter. Va specificato il tipo, vanno definiti i limiti che verranno controllati nel setter, va generato un mapping che permetta allo slave I2C di metterla a disposizione sotto un certo indirizzo. Va specificato se lo slave I2C può solo leggere o anche scrivere. Va generato un meccanismo che permetta ad un callback di registrarsi per una certa variabile e venir quindi chiamato se essa viene modificata.

Tutto ciò risulta in una certa quantità di codice che si ripete con differenze minime per ogni variabile che serve.

Automatizzare questo processo risparmia tempo, semplifica la documentazione (apri il file CSV in Excel e trovi tutto), riduce la probabilità di errori dovuti al centesimo copia-e-incolla e decuplica la mantenibilità.

fairyvilje ha scritto:Secondo me i file generati vanno versionati

Esco allo scoperto. Anche secondo me

ma in un repository separato e solo per un branch specifico del generatore

Qui non sono sicuro. Probabilmente non nuoce, ma si tratta di un progetto a cui lavorano 4 persone e quasi certamente il codice non verrà riciclato altrove.

IlGuru ha scritto:Otterreste n progetti tutti uguali alimentati solo dal generatore di codice.

Non capisco cosa intendi. Il progetto è uno ed è sempre lo stesso. Quando generarne una nuova revisione lo decide lo sviluppatore facendo un commit. Che le differenze siano nel file CSV, in un file autogenerato o in un file scritto a mano, fa poca differenza.

xyz ha scritto:nel repository deve finire solo il codice che genera il software

Sembra una finezza letteraria, ma non lo è: il codice che genera il software è il file C++, non lo script in python o il file CSV. Quindi, se facciamo come dici tu, il file C++ autogenerato va messo sotto version control. Che è esattamente quello che penso anch'io

Dimentichiamoci per un momento di quello che ho scritto e prendiamo utilizzi classici di toolchains molto diffuse: se genero un progetto per un microcontroller STM32, per comodità posso decidere di farlo usando STM32CubeMX. Cosa metto nel repository? Il file IOC usato dal CubeMX, i file C che genera o entrambi?
Non credo che ci sia chi metta in version control solo il file IOC.
(un discorso analogo si può fare per MCUXpresso, se preferite NXP).

fairyvilje ha scritto:A quel punto vuol dire che ogni sviluppatore, che python magari non vuole nemmeno toccarlo, è costretto a gestire in locale una sua distribuzione aggiornata con tutte le librerie rilevanti. Solo per poter usare del codice C++.

Stai descrivendo il mio stato d'animo?
Facciamo un esperimento mentale: questa storia non sta avvenendo ora, ma 10 anni fa e si è deciso di non mettere nel repository i files C++. Un paio di anni dopo c'è stato un release e il software è usato in un prodotto che viene venduto. Oggi un cliente si lamenta di un bug e noi dobbiamo scoprire cosa non funziona.
Mi esporto il repository e scopro che non ci sono tutti i files che mi servono. Mi ricordo che sono generati in automatico, quindi faccio partire python. Sorpresa, era stato scritto in Python 2.6 e serve anche una libreria non piú mantenuta che non so dove trovare... sarò anche una persona con poca pazienza, ma queste cose mi fanno imbestialire.

In questo contesto python va equiparato alla funzione di code completion della IDE.
In questo contesto python non va equiparato al compiler.

L'unico problema che vedo nel versionare i file C++ è che può succedere che lo sviluppatore sbadato faccia un commit senza aver prima avviato lo script di generazione, creando così una discrepanza tra file CSV e codice C++.
Ma si può sicuramente risolvere (sto pensando di versionare una checksum in un file separato o di confrontare le date di ultima modifica).
Il tutto viene compilato su un server di continuous integration, quindi abbiamo diverse possibilità in tal senso.

Boiler

Non so se può essere utile perché è un contesto molto più ridotto, ma provo a riportare la mia esperienza.
Come qualcuno sa, negli ultimi anni ho scritto diversi giochi di avventura testuale che ho fatto girare su numerosi computer "storici" ad 8 bit. Il metodo che utilizzo è quello di scrivere il gioco in una specie di linguaggio specializzato e poi far girare un convertitore chiamato AWS2C (scritto da me) per generare automaticamente del codice C. Questo codice è poi compilato da compilatori specifici ad ogni macchina.
Per ragioni di organizzazione (e perché la generazione avviene con modalità leggermente diverse) mi risulta comodo generare il codice C macchina per macchina.

Ho notato che è comodo tenere il codice generato sotto controllo di versione. Difatti mi è capitato di dover ricompilare il gioco per aggiustare alcune cose (per esempio aggiungere uno splash screen) senza dover rigenerare da zero il codice C. Dato che AWS2C è stato sviluppato anche lui via via che i giochi sono scritti, mi è capitato di introdurre alcune piccole incompatibilità che avrebbero rischiato di creare dei problemi. Nulla di irrisolvibile data la scala di cui si sta parlando. Tuttavia è stato comodo avere sempre sottomano il codice generato

Grazie DarwinNE per aver condiviso la tua esperienza

Nota a margine, conosci questo: https://www.jetbrains.com/mps/
È una di quelle cose che ti fa perdere tanto tempo quanto ne risparmi, quindi a bilancio nullo, ma di una bellezza impressionante. È gratuito e la casa che lo produce è JetBrains, un nome una garanzia.

Boiler

boiler ha scritto:...
Per ognuna di queste variabili va generato un getter e un setter. Va specificato il tipo, vanno definiti i limiti che verranno controllati nel setter, va generato un mapping che permetta allo slave I2C di metterla a disposizione sotto un certo indirizzo. Va specificato se lo slave I2C può solo leggere o anche scrivere. Va generato un meccanismo che permetta ad un callback di registrarsi per una certa variabile e venir quindi chiamato se essa viene modificata
...

In passato ho avuto le stesse esigenze su del codice per micro controllore (Atmel AVR a 8 bit) ho risolto semplicemente utilizzando il C++ (non completo ma un subset) con i template. Ho sempre controllato il codice generato (ho esaminato quello assembler) era sempre ottimizzato al massimo da parte del compilatore ogni volta che venivano usate le variabili instanziate con un opportuno template con tutte le operazione che hai indicato in aggiunta anche quelle con accesso atomico nel caso di codice multi-thread.