Come organizzare il sistema di generazione di un progetto quando inizia a includere più lingue su più sistemi operativi e compilatori?

-1

Ho scritto un lettore musicale e libreria in Java per GNU / Linux e Windows.

Il mio processo di compilazione è attualmente in ANT, ma ho intenzione di migrare da quello a qualcosa di più moderno dopo la prossima versione. Ho sentito cose positive sul gradle, ma se c'è qualcosa di più adatto che vorresti raccomandare, sono aperto a questo.

Il progetto era originariamente in puro Java, ma per ottenere l'accesso a determinate funzionalità, ho dovuto iniziare a creare speciali caratteristiche native diverse e collegarle al mio programma usando JNI.

Ecco uno schema delle parti correnti:

  • Hypnos Base - scritto in Java, viene compilato in un barattolo.
  • JXGrabKey - Una libreria di tasti di scelta rapida open source esistente, modificata dal mio progetto per supportare javafx. Compilare a un jar incluso nel progetto tramite manifest.
  • Native Launcher GNU / Linux - scritto in C ++, compilato con g++ .
  • Windows Native Launcher - scritto in C ++, compilato con cl.exe .
  • Icona del vassoio GTK GNU / Linux - scritta in C, compilata con gcc .

Inoltre, dopo aver creato i vari elementi, unisco i pezzi e poi eseguo uno script NSIS per generare un programma di installazione di Windows e un programma AppImage per generare un'Immagine per Linux.

Per il codice compilato in modo nativo, lo stavo compilando a mano secondo le necessità e poi lo ho fornito ad ANT in formato binario per fare la mia confezione.

Poiché sto aggiungendo sempre più codice nativo, sto iniziando a voler essere in grado di ricompilare l'intero progetto su richiesta con il mio script di build piuttosto che dover eseguire manualmente ciascun modulo prima di avviare ANT. È irresponsabile avere un progetto open source in cui il processo di costruzione è arcano.

Il mio sistema di sviluppo primario è Ubuntu 18.04. Prima di oggi, tutto il codice di build era fattibile su quel sistema. Ora ho aggiunto il programma di avvio nativo per Windows, che è attualmente compilato con cl.exe e indirizza Windows a 64 bit. È un codice relativamente semplice (~ 60 righe) con una singola funzione, WinMain , una libreria di base che collega il lavoro e poi passa le cose a jvm.dll .

    
posta JoshuaD 02.12.2018 - 03:11
fonte

1 risposta

3

I sistemi di compilazione sono complessi

I sistemi di costruzione sono per necessità piuttosto complessi e internamente arcani. La parte importante è, come con il tuo lettore musicale, il modo in cui semplifica tale complessità per fornire alcune semplici azioni razionali all'utente del sistema di generazione. Quanto sono configurabili tali azioni dipenderà in gran parte dalla personalizzazione della build.

Generalmente il sistema di compilazione è responsabile di:

  • Analizzare la fonte per i problemi (linting, audit delle dipendenze, ecc ...)
  • Compilare la fonte in binari.
  • Test delle unità + copertura del codice.
  • Alcuni moduli leggeri / test di integrazione.
  • Packaging
  • Stampa
  • Distribuzione (in base a ciò che viene creato)

Organizzalo in base a deliverable.

Letteralmente, considera ogni parte come se fosse un progetto separato. Dare a ciascuno il proprio script di costruzione. In questo modo puoi scegliere il sistema di compilazione più adatto per quell'aspetto del tuo progetto.

Normalmente avresti un singolo script master che orchestra le sotto-build da costruire in un certo ordine senza conflitti ecc ... Questo master script sarebbe l'equivalente di te: costruzione parte 1, spostamento da x a y, costruzione parte 2, ....

Considerando che hai un progetto multipiattaforma, potrebbe non avere senso avere un solo script di master building. In questo caso, organizzare i sottoprogetti mediante un mix di piattaforma (per codice dipendente dalla piattaforma) e sottosistema (per codice cross-compilabile / indipendente dalla piattaforma). Utilizza uno script di piattaforma-master per orchestrare la costruzione di sottosistemi e codice dipendente dalla piattaforma.

Potrebbe avere senso estrapolare il sottosistema e gli script di compilazione della piattaforma master in progetti "pseudo" separati in quanto potrebbero dipendere da binari non creati localmente.

Organizzare in questo modo ti aiuterà a modulare e successivamente facilitare il processo di suddividere questo in repository separati. Inoltre, i singoli script di build renderanno molto più semplice la creazione di una pipeline di build per un server di sviluppo.

Repository binario

Poiché si dispone di un sistema multipiattaforma, e sembra che non si possa sperare di compattare tutto su una singola scatola, vorrei studiare un repository binario. Questo potrebbe essere semplice come un repository Git dedicato al check-in per creare risorse, una condivisione di file o un sistema di pacchetti. L'unico requisito reale è che puoi facilmente identificare l'ultima build rilasciabile appropriata e recuperarla.

Ora quando costruisci una versione rilasciabile, lo script di compilazione lo carica nel tuo repository binario. Quando un altro script di build ha bisogno di una dipendenza rilasciabile lo recupera, avvisa o fallisce quando non lo trova.

Gli strumenti di creazione

Esistono molti strumenti di sviluppo per orchestrare progetti. Gli strumenti di immissione più bassi sono gli script di shell (bash / powershell), direi che li utilizzo anche come wrapper attorno agli attuali strumenti di generazione.

Per quanto riguarda gli attuali strumenti di costruzione, ciò dipende molto dalle tue esigenze. Dai un'occhiata ai diversi strumenti di creazione disponibili e trova quelli che ti offrono la migliore esperienza. Dovrai bilanciare i vantaggi di questi strumenti, rispetto ai loro costi come l'installazione / versioning / configurazione rispetto alla scrittura di script shell / multipiattaforma.

Consigli generali

Personalmente non buttare Ant fuori dalla porta ancora. Date invece ai progetti più piccoli la creazione di script, quindi orchestrali (anche approssimativamente) con gli script della piattaforma principale. Mentre stai facendo questo esperimento con alcuni set di strumenti di compilazione diversi. Quando sei soddisfatto del nuovo set di strumenti di generazione, esegui la migrazione della build basata sulla formica.

Non preoccuparti eccessivamente se finisci usando tre (o più) sistemi di compilazione separati. Puoi in gran parte astrarre questi dettagli negli script di compilazione e fornire un follow me per configurare l'ambiente una volta spento. Se vuoi davvero che sia semplice per gli utenti finali, script uno script di verifica / installazione / aggiornamento per questi strumenti di sviluppo sulla piattaforma.

La parte più importante è però semplificare l'intero processo di compilazione fino a qualcosa come build sulla piattaforma A, quindi build sulla piattaforma B.

    
risposta data 03.12.2018 - 09:15
fonte

Leggi altre domande sui tag