编译单线程v。多线程（和lib命名约定）的重要性？

| [编辑] ==> 为了澄清，在将多个目标部署到同一目录的那些环境中，Planet Earth决定约定将\“

d

\”或\“

_d

\”或\“

_debug

\”附加到\“

DEBUG

\”版本（属于库或可执行文件）。可以将这样的约定视为“普遍存在”和“理解”，尽管（当然）不是每个人都这样做。 同样，要解决库的“共享”和“静态”版本之间的歧义，通常的约定是在静态和共享之间添加一些区别（例如对于共享导入，请使用\“

myfile.lib

\”）。 Windows上的lib）和Windows上的static-import-lib上的\“

myfile_s.lib

\”）。虽然Posix基于文件扩展名没有这种歧义，但是请记住，文件扩展名未在\“链接行\”上使用，因此，能够显式指定\“ static \”或\“ shared”同样有用。 \“版本的库。 出于这个问题的目的，\“

debug/release

\”和\“

static/shared

\”都被提升为“普遍存在的修饰文件名root \”。 问题：是否有任何其他部署配置被“提升”到这种“普遍存在的约定”级别，从而在文件目标根名称中变得显式？ 我目前的猜测是“否”。要使答案为“是”，将需要：打算为给定目标使用多个配置（“使用”）（并因此将其部署到公共目录，这是该问题的假定基础）。 过去，我们编译了有无Web插件功能，该功能同样需要名称修饰，但是我们不再构建这些目标（因此，我不会断言为例）。同样，有时我们会编译有无多字节字符支持，但是我讨厌这样做，因此我也不会断言。 [原始问题] 我们正在建立要在各种语言和平台上应用的库命名约定/策略（例如，我们在不同的平台（包括C / C ++，C＃，Java）上支持使用多种语言的混合产品。一个特殊的目标是确保除了传统的桌面（和嵌入式）应用程序之外，我们还要处理移动开发的目标/资源（对我们来说是新的）。 当然，一种选择是为来自不同构建配置的目标提供不同的路径。出于这个问题的目的，决定将所有目标共同放置在一个目录中，并“装饰”库/资源/可执行文件名称，以避免基于构建配置的冲突（例如，“ DEBUG” \“ v。” RELEASE \“，\”静态lib \“ v。\” shared / DLL \“等） 当前的决定与网络上的其他决定相似，我们在其中附加了标记以避免命名冲突：

  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)

（以上是Windows示例，但是这些策略类似地适用于我们的POSIX系统。） 这些基于：

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

问题：我们没有必须编译为单线程的旧应用程序，我的理解是（与Microsoft不同，）POSIX系统可以将单线程和多线程目标链接到单个应用程序中而不会出现问题。考虑到当今对多核和多线程的推动，大型企业是否需要建立以下对象来确定“单线程”与“多线程”编译目标？

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

...并且我们是否错过了其他任何目标冲突，例如在C ++上使用和不使用STL进行编译？ 顺便说一句，Microsoft在以下位置具有库命名约定： http://msdn.microsoft.com/zh-CN/library/aa270400(v=vs.60).aspx及其DLL命名约定位于：http://msdn.microsoft.com/zh-cn/library/aa270964 （v = vs.60）.aspx 一年前关于SO的类似问题，它没有讨论线程并且没有引用Microsoft约定，可以在以下位置找到：什么是MSVC dll，静态库和导入库的正确命名约定？