Diversi modi per distribuire la libreria modulare C (incorporata)

Question

Diversi modi per distribuire la libreria modulare C (incorporata)

#1 da (7 voti)

5

picoTCP (uno stack TCP / IP embedded open source) ha sempre avuto un focus sullo sviluppo (sia in picoTCP che in se stesso con picoTCP) su linux & sistemi gcc. L'obiettivo finale è solitamente un micro incorporato (basato su ARM). Per questo motivo inseriamo una certa logica nel makefile per mantenere alta la modularità. Stiamo anche utilizzando flag di compilazione per abilitare / disabilitare tutti questi moduli.

Iniziamo a notare che Linux non è l'unico sistema di sviluppo (qui intendo mentre utilizzo picoTCP nel tuo progetto) nel mondo e che Windows insieme a un gruppo di IDE con il proprio compilatore (proprietario) non sono buoni amici con i Makefile.

Questo di solito significa che questi utenti devono aggiungere manualmente i file picoTCP al loro progetto ed espandere il loro sistema di build. Ciò significa anche che le persone si imbattono in problemi come

quali file includere (perché la logica è nel Makefile)
in quale ordine devono essere inclusi
aggiorna manualmente tutti questi file quando c'è una nuova versione

Attualmente stiamo esaminando i diversi modi di distribuire picoTCP in un modo più conveniente e vorremmo conoscere i pro e i contro.

Al momento abbiamo identificato un paio di modi

Genera file .a

(+) Soluzione pulita che continua a utilizzare il Makefile esistente
(-) Richiede un Linux & ambiente gcc
(-) Funziona solo con lo stesso compilatore / sistema di destinazione

Genera un singolo file .c e .h

Questo è qualcosa che la libreria Mongoose di Cesanta fa

(+) Molto portatile e amp; semplice da usare
(-) Nightmare per eseguire il debug
(-) Avranno bisogno di script esterni per rimuovere #include e unire file insieme
(-) Verranno inclusi tutti i moduli, quindi probabilmente dovremo aggiungere altri flag di compilazione

Costruisci un generatore di libreria (basato sul web) (di nuovo un file .c e .h)

Qualcosa fatto comunemente nelle applicazioni web (come JQuery)

(+) Aiuta le persone nella creazione di una libreria ottimizzata
(+) basato sul Web, quindi non c'è bisogno di nessun ambiente
(-) La maggior parte del lavoro per configurare un tale sistema
(-) Come tenere traccia di molte versioni di librerie?

Potresti fornire commenti e altre alternative?

c embedded-systems distribution libraries

posta Phalox 30.12.2016 - 21:29

fonte

1 risposta

Leggi altre domande sui tag c embedded-systems distribution libraries

Quanta registrazione devo fare in produzione per SQLExcpetions? Devo creare un (nuovo) progetto per UserControls condivisi?

score 7 · Accepted Answer

Generate .a file

Build a (web-based) library generator (again one .c and .h file)

Nessuna di queste è una buona opzione. Il primo è, per la ragione che hai coperto, specifico per piattaforma. Quest'ultimo lascia chiunque voglia modificare l'insieme di moduli compilati nel proprio binario in base al fatto che si continua a eseguire un server in grado di generare una nuova versione. Potresti fornire i sorgenti per quel server, ma dovresti installarne uno solo per quello sarebbe scomodo o impossibile in alcuni negozi.

Generate a single .c and .h file

Penso che questo sia il modo migliore per andare da quando puoi generarlo come parte della tua distribuzione ed è sempre lo stesso.

(+) Very portable & simple to use

Il problema della portabilità è una cosa importante nello spazio integrato. Ci sono molti piccoli ambienti di sviluppo per varie piattaforme che non offrono molti dei tipi di funzionalità che si trovano in un ambiente Unix, quindi qualsiasi cosa tu possa fare per semplificare l'integrazione aumenterà l'adozione.

Un ulteriore vantaggio è che molti compilatori possono eseguire ottimizzazioni di dimensioni e velocità su un singolo file che non è possibile quando il codice è suddiviso. Essere in grado di spremere il tuo codice in un footprint più piccolo e strizzare di più è benvenuto in ambienti vincolati.

(-) Nightmare to do debugging

Non tanto quanto si potrebbe pensare. Alla maggior parte dei debugger non interessa se hai un file gigante o 50 piccoli. Una volta che hai risolto i nodi per determinare cosa viene incluso e cosa no, probabilmente non lo noterai perché la maggior parte del debugging viene eseguita all'interno della funzione. Le probabilità sono abbastanza buone che la maggior parte degli errori che incontrerai saranno dovuti a difetti nel codice e verranno visualizzati sia nelle versioni non unite che in quelle unite. A proposito della stessa, se hai una batteria di prova, sarebbe bene eseguirla contro entrambi.

Vuoi mantenere separati i file originali perché è molto più facile fare recensioni e spostarti nel tuo sistema di controllo della versione cercando blocchi più piccoli.

Un motivo per evitare build personalizzate per ciascuna combinazione di funzionalità è che mette in pratica 2 ^ n versioni del sorgente là fuori, dove n è il numero di funzionalità puoi abilitare o disabilitare. Se qualcuno segnala un bug nella riga 456, se sei il tuo sorgente, devi determinare se il set di funzionalità è abilitato in modo da sapere quale linea 456 è.

(-) Will need external scripts to remove #includes and merge files together

Questo non dovrebbe essere un grosso problema. L'importante è assicurarsi che il processo sia automatizzato e ripetibile, in modo che diventi una parte del processo di distribuzione definita e dimenticata.

(-) All modules would be included, therefore we'll probably have to add some more compilation flags

Questo non dovrebbe essere troppo dirompente, specialmente se hai già una selezione di funzionalità integrata nel codice. Se lo fai come parte del tuo ambiente di costruzione (ad esempio, la decisione di includere o escludere qualcosa fa parte del tuo Makefile, ti consiglio di scappare da quello.

Prima di immergerti in una distribuzione a file singolo, ti consiglio vivamente di studiare SQLite . Quel progetto è in circolazione da 16 anni, è praticamente il gold standard per quel genere di cose e fa molte delle cose che stai cercando di fare.