Como han dicho los demás, no existe una sola estándar para asignar nombres a los archivos en Windows.
Para nuestra base de productos completa que cubre 100 de exes, dlls y libs estáticas, hemos utilizado los siguientes exitosamente desde hace muchos años y ha ahorrado mucha confusión. Es básicamente una mezcla de varios métodos que he visto utilizar a lo largo de los años.
En pocas palabras, todos nuestros archivos de prefijo y sufijo (sin incluir la extensión en sí). Todos comienzan con "om" (basado en el nombre de nuestra empresa), y luego tienen una combinación de 1 o 2 caracteres que identifica aproximadamente el área del código.
El sufijo explica qué tipo de archivo incorporado son e incluye hasta tres letras combinadas dependiendo de la compilación que incluye Unicode, Static, Debug (las compilaciones Dll son las predeterminadas y no tienen un identificador de sufijo explícito). Cuando comenzamos este sistema, Unicode no era tan frecuente y tuvimos que admitir las compilaciones Unicode y Non-Unicode (antes del sistema operativo Windows 2000), ahora todo se construye exclusivamente unicode pero aún usamos la misma nomenclatura.
Así que un .lib típico "conjunto" de archivos podría parecerse a
omfThreadud.lib (Unicode/Debug/Dll)
omfThreadusd.lib (Unicode/Static/Debug)
omfThreadu.lib (Unicode/Release/Dll)
omfThreadus.lib (Unicode/static)
Todos los archivos están incorporados en una carpeta bin común, lo que elimina una gran cantidad de problemas de DLL-infierno para los desarrolladores y también hace es más fácil ajustar la configuración del compilador/enlazador; todos apuntan a la misma ubicación usando rutas relativas y nunca hay necesidad de copiar de forma manual (o automática) las bibliotecas que un proyecto necesita. Tener estos sufijos también elimina cualquier confusión sobre qué tipo de archivo puede tener, y le garantiza que no puede tener un escenario mixto donde deposite el dll de depuración en un kit de lanzamiento o viceversa. Todos los archivos también usan un sufijo similar (Unicode/Debug) y compilan en la misma carpeta bin.
También hay una sola carpeta "incluir", cada biblioteca tiene un archivo de encabezado en la carpeta de inclusión que coincide con el nombre de la biblioteca/dll (por ejemplo omfthread.h) Ese archivo en sí # incluye todos los otros elementos que están expuestos por esa biblioteca. Esto lo hace más sencillo si desea funcionalidad que está en foo.dll simplemente #include "foo.h"; nuestras bibliotecas están muy segmentadas por áreas de funcionalidad; de hecho, no tenemos ningún dll de "cuchillo suizo", por lo que la funcionalidad completa de las bibliotecas tiene sentido. (Cada uno de estos encabezados también incluye otros encabezados de requisitos previos, ya sean nuestras bibliotecas internas u otros SDK de proveedores)
Cada uno de estos archivos de inclusión utiliza internamente macros que usan # pramga para agregar el nombre de biblioteca apropiado a la línea del enlazador para proyectos individuales no necesita preocuparse por eso. La mayoría de nuestras bibliotecas se pueden construir estáticamente o como un DLL y #define OM_LINK_STATIC (si está definido) se usa para determinar qué proyecto individual desea (usualmente usamos los DLL pero en algunos casos las bibliotecas estáticas incorporadas en el .exe hacen más sentido para el despliegue o por otras razones)
#if defined(OM_LINK_STATIC)
#pragma comment (lib, OMLIBNAMESTATIC("OMFTHREAD"))
#else
#pragma comment (lib, OMLIBNAME("OMFTHREAD"))
#endif
Estas macros (OMLIBNAMESTATIC & OMLIBNAME) Uso _DEBUG determinar qué tipo de acumulación que es y generar el nombre de la biblioteca adecuada para añadir a la línea de enlace.
Usamos una definición común en las versiones estáticas & dll de una biblioteca para controlar la exportación adecuada de la clase/funciones en las compilaciones dll. Cada clase o función exportada desde la biblioteca está decorado con esta macro (cuyo nombre coincide con el nombre de base para la biblioteca, sin embargo, que es en gran parte poco importante)
class OMUTHREAD_DECLARE CThread : public CThreadBase
En la versión DLL de la configuración del proyecto definimos OMFTHREAD_DECLARE = __ declspec (dllexport), en la versión de biblioteca estática de la biblioteca definimos OMFTHREAD_DECLARE como vacío.
En las bibliotecas de cabecera del archivo lo definimos en función de cómo el cliente está tratando de enlazar con él
#if defined(OM_LINK_STATIC)
#define OMFTHREAD_DECLARE
#else
#define OMFTHREAD_DECLARE __declspec(dllimport)
#endif
Un proyecto típico que quiere usar una de nuestras bibliotecas internas que sólo tiene que añadir la adecuada incluyen a su stdafx.h (típicamente) y simplemente funciona, si necesitan vincularse con la versión estática simplemente agregan OM_LINK_STATIC a su configuración de compilación (o la definen en stdafx.h) y de nuevo solo funciona.
SCons también "crea (esto) colisión bastante desagradable" cuando se utiliza _env.SharedLibrary_ y _env.StaticLibrary_ con el mismo nombre de destino. –