Definizione di convenzione di denominazione appropriata per DLL di MSVC, librerie statiche e librerie di importazione

Question

Che cos'è la convenzione di denominazione standard o "più popolare" per i build di librerie MSVC.

Ad esempio, per le seguenti piattaforme biblioteca foo ha queste convenzioni:

Linux/GCC:

shared: libfoo.so 
import: --- 
static: libfoo.a 

Cygwin/gcc:

shared: cygfoo.dll 
import: libfoo.dll.a 
static: libfoo.a 

di Windows/MinGW:

shared: libfoo.dll 
import: libfoo.dll.a 
static: libfoo.a 

Che cosa dovrebbe essere usato per i buidls di MSVC? Per quanto ne so, i nomi di solito sono foo.dll e foo.lib, ma come si fa normalmente a distinguere tra libreria di importazione e quella statica?

Nota: Lo chiedo perché CMake crea abbastanza unpleasant collisione tra loro un nome sia di importazione e di libreria statica come foo.lib. Vedi bug report. La risposta sarebbe aiutarmi a convincere gli sviluppatori a risolvere questo bug.

Answer 1

È possibile distinguere tra una libreria e una DLL dall'estensione. Ma si fa una distinzione tra una libreria di importazione e una libreria statica tramite il nome file , non l'estensione.

Non ci saranno casi in cui esiste una libreria di importazione per un set di codice creato per essere una libreria statica o dove esiste una libreria statica per una DLL. Queste sono due cose diverse.

Non esiste una convenzione di nome file standard MSVC. Di regola, un nome di libreria che termina con "D" è spesso una build di debug del codice di libreria, msvcrtd.dll vs msvcrt.dll ma, a parte questo, non ci sono standard.

Answer 2

Come detto da altri, non ci sono standard, ma ci sono convenzioni popolari. Non sono sicuro di come giudicare senza ambiguità qual è la convenzione più popolare. Oltre alla nomenclatura per le librerie statiche e di importazione, che hai chiesto, esiste anche una distinzione analoga tra la denominazione delle librerie Release e le librerie Debug, specialmente su Windows.

Entrambi i casi (vale a dire statico vs importazione e debug contro versione) possono essere gestiti in due modi: nomi diversi o posizioni di directory diverse. Di solito scelgo di usare nomi diversi, perché ritengo che riduca al minimo la possibilità di confondere il tipo di libreria più tardi, soprattutto dopo l'installazione o altre attività di spostamento dei file.

Io di solito uso foo.dll e foo.lib per la libreria condivisa su Windows e foo_static.lib per la libreria statica, quando desidero avere sia versioni condivise che statiche. Ho visto gli altri usare questa convenzione, quindi potrebbe essere la "più popolare".

Quindi mi sento di raccomandare la seguente aggiunta al vostro tavolo:

di Windows/MSVC:

shared: foo.dll 
import: foo.lib 
static: foo_static.lib 

Poi, nel CMake, si potrebbe o

add_library(foo_static STATIC foo.cpp) 

o

add_library(FooStatic STATIC foo.cpp) 
set_target_properties(FooStatic PROPERTIES OUTPUT_NAME "foo_static") 

se per qualche motivo non si desidera utilizzare "foo_static" come nome della libreria simbolica.

Answer 3

Per quanto ne so, non esiste un vero "standard", almeno nessuno standard per la maggior parte del software sarebbe conforme.

La mia convenzione è denominare il mio dinamico e statico .lib ugualmente, ma inserirli in directory diverse se un progetto capita di supportare sia il collegamento statico che dinamico.Per esempio:

foo-static 
    foo.lib 

foo 
    foo.lib 
    foo.dll 

La biblioteca di collegare contro dipende dalla scelta delle directory di libreria, quindi è quasi totalmente disaccoppiato dal resto del processo di generazione (non sarà visualizzato in-source, se si utilizza MSVC di #pragma comment(lib,"foo.lib") funzionalità, e non compare nell'elenco delle librerie di importazione per il linker).

L'ho visto diverse volte. Inoltre, penso che i progetti basati su MSVC/Windows tendono ad attaccare più spesso con un unico tipo di collegamento ufficiale: statico, o dinamico. Ma questa è solo la mia osservazione personale.

In breve: di Windows/MSVC

shared: foo.dll 
import: foo.lib 
static: foo.lib 

Si dovrebbe essere in grado di utilizzare questo modello basata su directory con CMAKE (mai usata). Inoltre, non penso che sia un 'bug'. È semplicemente la mancanza di standardizzazione. CMAKE fa (imho) la cosa giusta non per stabilire uno pseudo-standard se a tutti piace in modo diverso.

Answer 4

Non esiste una convenzione di denominazione standard per le librerie. I nomi delle librerie tradizionali hanno il prefisso lib. Molti linker hanno opzioni per anteporre lib a un nome di libreria sulla riga di comando.

Le librerie statiche e dinamiche sono generalmente identificate dalla relativa estensione; anche se questo non è richiesto. Quindi libmath.a sarebbe una libreria statica mentre libmath.so o libmath.dll sarebbe una libreria dinamica.

Una convenzione di denominazione comune è quella di aggiungere la categoria della libreria al nome. Ad esempio, una libreria di matematica statica di debug sarebbe "libmathd.a" o in Windows, "lib_math_debug". Alcuni negozi aggiungono anche Unicode come attributo nomefile.

Se lo si desidera, è possibile aggiungere _msvc al nome della libreria per indicare che la libreria richiede o è stata creata da MSVC (per differenziare da GCC e altri strumenti). Una convenzione popolare quando si lavora con più piattaforme consiste nel posizionare gli oggetti e le librerie in cartelle specifiche della piattaforma. Ad esempio una cartella ./linux/ conterrà oggetti e librerie per Linux e allo stesso modo ./msw/ per la piattaforma Microsoft Windows.

Questo è un problema di stile. I problemi di stile sono spesso trattati come questioni religiose: nessuno di loro è sbagliato, non esiste uno stile universale e sono una preferenza individuale. Qualunque sistema tu scelga, sii coerente.

Answer 5

Come gli altri hanno già detto, non esiste un singolo standard per denominare i file su Windows.

Per la nostra base di prodotti completa che copre centinaia di exe, DLL e librerie statiche, abbiamo utilizzato con successo le seguenti operazioni per molti anni e ha salvato molta confusione. È fondamentalmente un mix di diversi metodi che ho visto usato nel corso degli anni.

In breve tutti i nostri file di prefisso e suffisso (esclusa l'estensione stessa). Iniziano tutti con "om" (basato sul nome della nostra azienda), e quindi hanno una combinazione di 1 o 2 caratteri che identifica approssimativamente l'area del codice.

Il suffisso spiega che tipo di file incorporato sono e include un massimo di tre lettere utilizzate in combinazione a seconda della build che include Unicode, Statico, Debug (le build di Dll sono predefinite e non hanno identificatore di suffisso esplicito). Quando abbiamo avviato questo sistema, Unicode non era così diffuso e abbiamo dovuto supportare sia build Unicode che Non-unicode (pre Windows 2000 os), ora tutto è esclusivamente costruito in Unicode ma usiamo ancora la stessa nomenclatura.

Quindi un tipico lib "set" di file potrebbe essere simile

omfThreadud.lib (Unicode/Debug/Dll) 
omfThreadusd.lib (Unicode/Static/Debug) 
omfThreadu.lib (Unicode/Release/Dll) 
omfThreadus.lib (Unicode/static) 

Tutti i file sono built-in in una cartella bin comune, che elimina un sacco di problemi di dll-hell per gli sviluppatori e rende anche è più semplice regolare le impostazioni del compilatore/linker: puntano tutte alla stessa posizione usando percorsi relativi e non c'è mai bisogno di copiare manualmente (o automaticamente) le librerie necessarie per un progetto. Avere questi suffissi elimina anche qualsiasi confusione sul tipo di file che si può avere e garantisce che non si può avere uno scenario misto in cui si mette giù la dll di debug su un kit di rilascio o viceversa. Tutti gli ex utilizzano anche un suffisso simile (Unicode/Debug) e vengono creati nella stessa cartella bin.

C'è anche una singola cartella "include", ogni libreria ha un file di intestazione nella cartella include che corrisponde al nome della libreria/dll (ad esempio omfthread.h) che il file stesso include tutti gli altri elementi che sono esposti da quella libreria. Questo è più semplice se si desidera funzionalità che è in foo.dll si #include semplicemente "foo.h"; le nostre librerie sono molto segmentate per aree di funzionalità - in effetti non abbiamo alcuna dll "swiss-army knife", quindi includendo le librerie tutta la funzionalità ha senso. (Ognuna di queste intestazioni include anche altre intestazioni prerequisite se esse sono le nostre librerie interne o altri SDK del fornitore)

Ciascuno di questi include file interni utilizza macro che utilizzano # pramga per aggiungere il nome della libreria appropriato alla riga del linker in modo che singoli progetti non è necessario preoccuparsi di questo. La maggior parte delle nostre librerie può essere compilata staticamente o come DLL e #define OM_LINK_STATIC (se definito) viene utilizzato per determinare quale progetto desidera (solitamente usiamo le DLL ma in alcuni casi le librerie statiche incorporate nel file .exe) più senso per la distribuzione o per altre ragioni)

#if defined(OM_LINK_STATIC) 
#pragma comment (lib, OMLIBNAMESTATIC("OMFTHREAD")) 
#else 
#pragma comment (lib, OMLIBNAME("OMFTHREAD")) 
#endif 

Queste macro (OMLIBNAMESTATIC & OMLIBNAME) utilizzare _DEBUG determinare il tipo di costruzione che è e generare il nome della libreria corretta per aggiungere alla linea di linker.

Utilizziamo una definizione comune nelle versioni statiche & dll di una libreria per controllare l'esportazione corretta della classe/delle funzioni nelle build di dll. Ogni classe o funzione esportata dalla libreria è decorato con questa macro (il cui nome corrisponde al nome di base per la libreria, anche se questo è in gran parte poco importante)

class OMUTHREAD_DECLARE CThread : public CThreadBase 

Nella versione DLL delle impostazioni del progetto definiamo OMFTHREAD_DECLARE = __ declspec (dllexport), nella versione della libreria statica della libreria definiamo OMFTHREAD_DECLARE come vuoto.

Nelle biblioteche intestazione del file lo definiamo in base a come il client sta tentando di collegare ad esso

#if defined(OM_LINK_STATIC) 
#define OMFTHREAD_DECLARE 
#else 
#define OMFTHREAD_DECLARE __declspec(dllimport) 
#endif 

Un progetto tipico che vuole utilizzare una delle nostre biblioteche interne sarebbe solo aggiungere l'appropriato comprendono al loro stdafx.h (tipicamente) e funziona, se hanno bisogno di collegarsi alla versione statica aggiungono semplicemente OM_LINK_STATIC alle loro impostazioni del compilatore (o lo definiscono nello stdafx.h) e funziona di nuovo.

Answer 6

Per quanto ne so, non esistono ancora convenzioni in merito. Ecco un esempio di come lo faccio:

{progetto} {modulo} {Piattaforma} {Architettura} {CompilerRuntime} _ {buildtype} lib/dll

Il nome del file completo sarà in minuscolo solo e contiene solo caratteri alfanumerici con caratteri di sottolineatura predefiniti. Il campo del submodule, incluso il suo underscore principale, è facoltativo.

Progetto: contiene nome/identificatore del progetto. Preferibilmente il più breve possibile. es. "dna"

SubModule: opzionale. contiene il nome del modulo. Preferibilmente il più breve possibile. es. "dna_audio"

Piattaforma: identifica la piattaforma per cui è stato compilato il binario. cioè "win32" (Windows), "winrt", "xbox", "android".

Architettura: descrive l'architettura per cui è stato compilato il binario. cioè "x86", "x64", "arm". Lì dove i nomi di architettura sono uguali per i vari testimoni usa il suo nome seguito dal testimone. vale a dire. "name16", "name32", "name64"

CompilerRuntime: facoltativo. Non tutti i binari collegano a un runtime del compilatore, ma se lo fanno, sono inclusi qui. cioè "vc90" (Visual Studio 2008), "gcc". Dove applicabile appartamento può essere incluso cioè "vc90mt"

BuildType: facoltativo. Questo può contenere lettere (in qualsiasi ordine desiderato), ognuna delle quali indica qualcosa sulle specifiche della build. d = debug (omesso se release) t = statica (omesso se dinamico) a = ANSI (omesso se unicode)

Esempi (supponendo un progetto denominato "DNA"): dna_win32_x86_vc90.lib/dll dna_win32_x64_vc90_d.lib/dll dna_win32_x86_vc90_sd.lib dna_audio_win32_x64_vc90.lib/dll dna_audio_winrt_x64_vc110.lib/dll