Dove inserisco le librerie di terze parti per configurare un ambiente di sviluppo Linux C++?

Dove mettere le librerie

La soluzione migliore è usare il sistema di impacchettamento della tua distribuzione Linux (apt-get , yum , o simili) per installare le librerie dai pacchetti forniti dalla distribuzione ove possibile.

Se le librerie pacchettizzate della distribuzione non sono di una versione abbastanza recente, o se hai bisogno di alcune opzioni di compilazione non standard, o se hai bisogno di una libreria che la tua distribuzione non fornisce, puoi crearla e installarla tu stesso. Hai due opzioni principali su dove mettere la libreria:

• /usr/local (librerie sotto /usr/local/lib , intestazioni sotto /usr/local/include ). Questo installa le librerie in tutto il sistema ed è probabilmente la soluzione più semplice, dal momento che dovresti essere in grado di costruire su di esse senza fare ulteriori passaggi. NON installare le librerie direttamente sotto /usr , poiché ciò interferirà con il sistema di pacchettizzazione della tua distribuzione.
• Nella directory del tuo progetto, come hai fatto in Windows. Ciò ha i vantaggi di non richiedere l'accesso root e di non apportare modifiche a livello di sistema, ma dovrai aggiornare i percorsi di inclusione e i percorsi di libreria del tuo progetto e dovrai inserire tutti i file di libreria condivisa in un punto in cui il linker dinamico può trovarli ( usando LD_LIBRARY_PATH o ld.so.conf - vedi il link per maggiori dettagli).

Come funzionano le librerie

Vedere l'eccellente Programming Library HOWTO di David A. Wheeler. Consiglierei di leggerlo e di pubblicare eventuali domande specifiche come nuovi argomenti.

Come distribuire il tuo programma

Tradizionalmente, i programmi Unix/Linux non includono copie delle loro dipendenze. Spetta invece all'utente finale o allo sviluppatore installare tali dipendenze da soli. Questo può richiedere un "LEGGIMI di grandi dimensioni", come hai detto, ma presenta alcuni vantaggi:

• Le librerie di sviluppo possono essere installate, gestite e aggiornate tramite il gestore pacchetti della distribuzione, invece che ogni copia sorgente abbia il proprio set di librerie da tenere traccia.
• C'è solo una copia di una data libreria su un sistema, quindi c'è solo un posto che deve essere aggiornato se, ad esempio, viene rilevata una falla di sicurezza. (Ad esempio, considera il caos che si è verificato quando si è scoperto che zlib, una libreria di compressione molto utilizzata, presentava un difetto di sicurezza, quindi ogni applicazione che includeva una versione interessata doveva essere aggiornata.)
• Se il tuo programma è abbastanza popolare (ed è open source o almeno disponibile gratuitamente), allora i manutentori di pacchetti per varie distribuzioni Linux potrebbero volerlo impacchettare e includerlo nella loro distribuzione. Manutentori dei pacchetti davvero non mi piacciono le librerie in bundle. Vedi, ad esempio, la pagina di Fedora sull'argomento.

Se stai distribuendo il tuo programma agli utenti finali, potresti prendere in considerazione l'idea di offrire un pacchetto (.dpkg o .rpm ) che potevano semplicemente scaricare e installare senza dover utilizzare i sorgenti. Idealmente, dal punto di vista dell'utente finale, il pacchetto verrebbe aggiunto ai repository delle distribuzioni (se è open source o almeno disponibile gratuitamente) in modo che gli utenti possano scaricarlo utilizzando i propri gestori di pacchetti (apt-get o yum ). Tutto questo può diventare complicato, a causa del gran numero di distribuzioni Linux là fuori, ma un .dpkg compatibile con Debian/Ubuntu e un .rpm compatibile con Red Hat/CentOS/Fedora dovrebbe coprire una buona percentuale di utenti finali. Costruire pacchetti non è troppo difficile e ci sono buoni howto online.

per la prima parte della tua domanda su Windows:non esiste un vero posto standard per librerie/intestazioni su Windows, quindi la soluzione semplice è:creane una tua. Fornisci semplicemente un singolo lib/ e include/ sul tuo sistema e fai in modo che tutti i tuoi progetti lo usino (impostando il percorso in un file cmake che includi ovunque). Inserisci lì tutte le librerie di terze parti, ad esempio:

i tuoi progetti:

d:/projects/projectA
d:/projects/projectB

roba di terze parti:

d:/api/lib/lua.lib
d:/api/include/lua/....

(puoi anche usare collegamenti simbolici, detti anche "incroci di directory" se hai una versione diversa)

e il file cmake corrispondente:

include_directories( d:/api/include )
link_directories( d:/api/lib )