Importanza della compilazione v single-threaded. Multi-threaded (e lib convenzioni di denominazione)?

Question

[EDIT] ==> Per chiarire, in quegli ambienti in cui più bersagli vengono distribuiti nella stessa directory, Pianeta Terra ha deciso su una convenzione per aggiungere "d" o "_d" o "_debug" per la versione "DEBUG" (di una raccolta o eseguibile). Tale convenzione può essere considerato "onnipresente" e "compresa", anche se (ovviamente) non tutti lo fanno.

Analogamente, per risolvere ambiguità tra le versioni "statici" di una libreria "condivisa" e, una convenzione comune è quello di aggiungere qualcosa di distinguere tra la statica e condivisa (come "myfile.lib" per shared-import-lib-on -Windows e "myfile_s.lib" per statico-import-lib-on-Windows). Mentre Posix non ha questa ambiguità base all'estensione del file, si ricordi che l'estensione del file non viene utilizzato sulla "linea di contatto", quindi è altrettanto utile per essere in grado di specificare in modo esplicito il "statica" o "condiviso" versione di una libreria .

Ai fini di questa domanda, sia "debug/release" e "static/shared" sono promossi a "convenzione onnipresente per decorare la radice nome del file" .

DOMANDA:? Fa qualsiasi altro get configurazione della distribuzione "promosso" a questo livello di "convenzione onnipresente" in modo tale che sarebbe diventato esplicito nel nome principale di destinazione del file

La mia ipotesi attuale è "no". Per la risposta sia "sì", sarebbe necessario:. Più di una configurazione per il dato obiettivo è destinato a essere "usato" (e quindi distribuito a una directory comune, che è la base ipotizzato per la domanda)

In passato, abbiamo compilato con-e-senza "web plug-in" capacità, che allo stesso modo necessario che la decorazione nome, ma non siamo più a costruire tali obiettivi (quindi non lo farò affermare che come esempio). Allo stesso modo, a volte compilare con-e-senza il supporto dei caratteri multi-byte, ma io odio che, quindi non lo farò affermare che sia.

[domanda iniziale]

Stiamo stabilire convenzioni di denominazione della biblioteca / politica, da applicare attraverso linguaggi e piattaforme (ad esempio, sosteniamo prodotti ibridi che utilizzano diverse lingue su diverse piattaforme, tra cui C / C ++, C #, Java). Un obiettivo particolare è quello di garantire la gestiamo obiettivi / risorse per lo sviluppo mobile (che è nuovo per noi) in aggiunta al nostro desktop tradizionale (e embedded) applicazioni.

Naturalmente, una è quella di avere percorsi diversi per target di diverse configurazioni di compilazione. Ai fini di questa domanda, la decisione è fatto per avere tutti gli obiettivi di co-localizzare ad una singola directory, e di "decorare" la libreria / risorsa / nome del file eseguibile a collisioni Evita in base alla configurazione costruzione (ad esempio, "DEBUG" v. "RELEASE", "lib statica" v "condiviso / DLL", ecc.)

decisione attuale è simile ad altri sul web, dove i token di accodamento per evitare di nominare le collisioni:

  MyName.lib           (release build, import for shared/dll)
  MyName_s.lib         (release build, static lib)

  MyName_d.lib         (debug build, import for shared/DLL)
  MyName_ud.lib        (Unicode/wide-char, debug, import for shared/DLL)
  MyName_usd.lib       (Unicode/wide-char, static lib, debug)

(Quanto sopra sono esempi di Windows, ma queste politiche in modo simile si applicano ai nostri sistemi POSIX.)

Questi sono basati su:

  d     (release or debug)
  u     (ASCII or Unicode/wide-char)
  s     (shared/DLL or static-lib)

DOMANDA: Non abbiamo le applicazioni legacy che devono essere compilati a thread singolo, e la mia comprensione è che (a differenza di Microsoft) sistemi POSIX possono collegare gli obiettivi mono e multi-threaded in un'unica applicazione senza alcun problema. Data la spinta di oggi verso il multi-core e multi-threaded, C'è bisogno di un grande impresa per stabilire quanto segue per identificare i "single" contro "multi-threaded" obiettivi compilati?

  t       (single-threaded or multi-threaded)  *(??needed??)*

... e abbiamo ci manca qualsiasi altra collisione bersaglio, come compilazione con-e-senza STL (su C ++)?

Per inciso, Microsoft ha convenzioni di denominazione di libreria a: http://msdn.microsoft.com/en -us / library / aa270400 (v = vs.60) aspx e their DLL convenzioni di denominazione in: http: // msdn .microsoft.com / en-us / library / aa270964 (v = vs.60) aspx

Una domanda simile su SO un anno fa che non ha parlato di filettatura e non fare riferimento alle convenzioni di Microsoft sono disponibili all'indirizzo: ciò che è proprio convenzione di denominazione per le DLL MSVC, librerie statiche e importare librerie

Answer 1

Si sta utilizzando un antico compilatore. Non v'è alcuna necessità di stabilire tale standard un in un'impresa, il venditore ha già fatto. Microsoft non ha fornito una versione single-threaded del CRT negli ultimi 13 anni. Allo stesso modo, Windows è stato un sistema operativo Unicode per gli ultimi 17 anni. Rende lo zero senso ancora scrivere codice Unicode agnostico in questi giorni.

Ma sì, la convenzione comune è quello di aggiungere una "d" per il build di debug di una libreria. E per dare una versione DLL di una libreria un nome completamente diverso.