È possibile spedire librerie con codice?

Question

È possibile spedire librerie con codice?

#1 da (1 voti)

0

Esiste un modo per includere in modo sicuro le librerie (interne o esterne) nella directory di un progetto (ad esempio in una cartella / lib) quando spedite o rilasciate il codice? Per quanto posso vedere, sarebbe molto più semplice se i file della libreria da cui dipendeva l'applicazione fossero collocati lì; in questo modo, altre persone che desiderano utilizzare il codice non dovranno scaricare, compilare e installare le librerie sul proprio sistema (nella cartella / usr / local / lib o allo stesso modo). Se questo è possibile (o consigliabile), allora altre persone potrebbero semplicemente clonare l'intera directory incluse le librerie, qualcosa come cmake potrebbe impostare il linker per raccogliere queste librerie e gli utenti potrebbero quindi semplicemente emettere un cmake e fare il comando piuttosto che installare prima le librerie sul proprio sistema.

Sono certo che questo potrebbe non funzionare se le due macchine hanno un diverso ordine di byte o lunghezza di parole, ma escludendo queste, c'è qualche ragione per non mettere semplicemente i file .a o .so con il tuo codice?

Se non è possibile (o consigliato per qualche motivo) includere i file della libreria con il codice sorgente, allora ci sono alternative per scaricare l'altro utente, compilarlo e installarlo sulla propria macchina? Contenitori (Docker) o gestori delle dipendenze (Conan) forse?

P.S. Sto parlando di sviluppo c / c ++ in ambienti Linux esclusivamente per applicazioni desktop.

libraries dependencies dependency-management

posta Andrew Murtagh 25.08.2017 - 22:22

fonte

1 risposta

Leggi altre domande sui tag libraries dependencies dependency-management

Progetto per coordinatore di collegamento record Il modo migliore per tenere traccia delle modifiche dell'utente

score 1 · Answer 1

Se le dipendenze sono popolari (come ffmpeg), di solito possono essere distribuite attraverso apt-get o yum . Questo è di fatto un modo standard per distribuire le dipendenze e ha il vantaggio di essere uno script (in questo modo è possibile includere uno script all'interno della fonte che installa tali dipendenze). Se le dipendenze non sono così popolari, potrebbero comunque essere disponibili attraverso un repository di terze parti. Ciò richiede operazioni aggiuntive, ma è possibile aggiungerle facilmente allo script.

Se stai parlando delle librerie che non sono disponibili come prodotti stand-alone, allora un gestore di pacchetti è davvero un'ottima alternativa. In alcune comunità, quei gestori di pacchetti sono diventati standard ( npm per Node.js, pip per Python, ecc.) Non avendo familiarità con C ++, non ho usato Conan, quindi puoi verificare se tra le alternative, quella tu userai sarà il più popolare.

Non includere librerie di terze parti nel tuo repository. Tra gli altri problemi:

Rende l'installazione inutilmente complessa e non standard.
Qualcuno dovrà gestire un caso in cui la dipendenza è già installata sul computer dell'utente, inclusa una versione precedente o successiva (entrambe le situazioni sono molto difficili da gestire).
Aumenta le dimensioni del codice sorgente.
Ogni volta che viene rilasciata una nuova versione della libreria di terze parti, è necessario aggiornare l'intero codice sorgente (se lo si memorizza come sorgente) o un gruppo di file binari (se si memorizzano i file binari) nel repository. Confrontalo con un semplice cambio di versione nel file che contiene l'elenco dei pacchetti di terze parti.