MSVC DLL、静态库和导入库的正确命名约定是什么

MSVC库构建的标准或“最流行”命名约定是什么

例如，对于以下平台，库

foo

具有以下约定：

Linux/gcc：

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

Cygwin/gcc：

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

Windows/MinGW：

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

MSVC构建应该使用什么？据我所知，通常名称是

foo.dll

和

foo.lib

，但您通常如何区分导入库和静态库

注意：我这样问是因为

CMake

在将导入库和静态库命名为

foo.lib

时会产生很大的冲突。看见答案是

---

请帮助我说服开发人员修复此错误。

正如其他人提到的，没有标准，但有流行的惯例。我不知道如何明确地判断什么是最受欢迎的惯例。除了您询问的静态库和导入库的命名法之外，发布库和调试库的命名之间还有类似的区别，尤其是在Windows上

这两种情况（即静态与导入、调试与发布）都可以通过以下两种方式之一进行处理：不同的名称或不同的目录位置。我通常选择使用不同的名称，因为我觉得这样可以最大限度地减少以后误认库类型的机会，尤其是在安装或其他文件移动活动之后

我通常使用

foo.dll

和

foo.lib

作为Windows上的共享库，而

foo\u static.lib

作为静态库，当我希望同时拥有共享和静态版本时。我见过其他人使用这个惯例，所以它可能是“最流行的”

因此，我建议在您的表格中添加以下内容：

Windows/MSVC：

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

那么在cmake，你可以

add_library(foo_static STATIC foo.cpp)

或

---

如果出于某种原因，您不希望使用“foo_static”作为符号库名称。

据我所知，没有真正的“标准”，至少大多数软件都不符合标准

我的习惯是将我的动态和静态

.lib

名称相等，但如果一个项目恰好同时支持静态和动态链接，则将它们放在不同的目录中。例如：

foo-static
   foo.lib

foo
   foo.lib
   foo.dll

要链接的库取决于库目录的选择，因此它几乎与构建过程的其余部分完全解耦（如果使用MSVC的

#pragma comment（lib，“foo.lib”）

功能，它不会出现在源代码中，也不会出现在链接器的导入库列表中）

我已经看过好几次了。此外，我认为基于MSVC/Windows的项目更倾向于使用单一的官方链接类型——静态或动态链接。但这只是我个人的观察

简言之： Windows/MSVC

---

您应该能够将此基于目录的模式与CMAKE一起使用（从未使用过）。而且，我不认为这是一个“错误”。这只是缺乏标准化。如果每个人都喜欢不同的伪标准，那么CMAKE（imho）不建立伪标准是正确的。

库没有标准命名约定。传统库名称的前缀为

lib

。许多链接器都可以在命令行中将

lib

前置到库名称

静态库和动态库通常通过它们的文件扩展名来标识；虽然这不是必需的。因此

libmath.a

将是一个静态库，而

libmath.So

或

libmath.dll

将是一个动态库

常见的命名约定是将库的类别附加到名称。例如，调试静态数学库应该是“libmathd.a”，或者在Windows中是“lib_math_debug”。一些商店还将Unicode添加为文件名属性

如果需要，可以将

\u msvc

附加到库名称，以指示库需要或由msvc创建（以区别于GCC和其他工具）。在使用多个平台时，一个流行的约定是将对象和库放置在特定于平台的文件夹中。例如，一个

/linux/

文件夹将包含linux的对象和库，类似地，也包含Microsoft Windows平台的

/msw/

---

这是一个风格问题。风格问题通常被视为宗教问题：没有一个是错误的，没有普遍的风格，它们是个人的偏好。无论您选择哪种系统，都要保持一致。

正如其他人所说，windows上的文件命名没有单一的标准

对于我们涵盖100个EXE、DLL和静态LIB的完整产品库，我们已经成功地使用了以下内容很多年，并且避免了很多混乱。这基本上是我多年来看到的几种方法的混合

简而言之，我们所有的文件都有前缀和后缀（不包括扩展名本身）。它们都以“om”（基于我们公司的名称）开头，然后有一个1或2个字符的组合，大致标识代码区域

后缀解释生成文件的类型，并根据包含Unicode、Static和Debug（默认为Dll生成，没有明确的后缀标识符）的生成，最多包含三个字母组合使用。当我们开始这个系统时，Unicode并不是很流行，我们必须同时支持Unicode和非Unicode构建（Windows 2000操作系统之前），现在所有东西都是Unicode专有构建的，但我们仍然使用相同的术语

因此，一组典型的.lib文件可能如下所示

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

所有文件都内置在一个公共bin文件夹中，这为开发人员消除了许多dll地狱问题，也使调整编译器/链接器设置变得更简单-它们都使用相对路径指向同一位置，并且不需要手动（或自动）复制项目所需的库。有这些后缀的

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

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

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

class OMUTHREAD_DECLARE CThread : public CThreadBase

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