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

发布于 2024-11-14 18:32:28 字数 2707 浏览 2 评论 0原文

[编辑]==> 为了澄清，在多个目标部署到同一目录的环境中，Planet Earth 决定采用一种约定来附加“d”或“_d”或“_debug”到“DEBUG”版本（库或可执行文件）。这样的约定可以被认为是“无处不在”和“理解的”，尽管（当然）并不是每个人都这样做。

同样，为了解决库的“共享”版本和“静态”版本之间的歧义，常见的约定是附加一些内容来区分静态版本和共享版本（例如“myfile.lib”表示共享版本） -import-lib-on-Windows 和“myfile_s.lib”（用于 static-import-lib-on-Windows）。虽然 Posix 没有这种基于文件扩展名的歧义，但请记住，文件扩展名不在“链接行”上使用，因此能够显式指定库的“静态”或“共享”版本同样有用。

出于这个问题的目的，“debug/release”和“static/shared”都被提升为“装饰文件名根的普遍约定”< /em>。

问题：是否有任何其他部署配置被“提升”到这种“普遍约定”级别，以便它在文件目标根名称中变得明确？

我当前的猜测是“不”。对于“是”的答案，需要：给定目标的多个配置旨在“使用”（并因此部署到一个公共目录，这是该问题的假定基础）。

过去，我们编译了带或不带“Web 插件”功能的代码，这同样需要名称修饰，但我们不再构建这些目标（因此我不会以此作为示例来断言）。同样，我们有时会在有或没有多字节字符支持的情况下进行编译，但我讨厌那样，所以我也不会断言这一点。

[原始问题]

我们正在建立库命名约定/政策，跨语言和平台应用（例如，我们支持使用不同平台上的多种语言，包括 C/C++、C#、Java）。一个特定的目标是确保除了传统的桌面（和嵌入式）应用程序之外，我们还处理移动开发的目标/资源（这对我们来说是新的）。

当然，一个选项是为来自不同构建配置的目标提供不同的路径。出于此问题的目的，决定将所有目标共同定位到单个目录，并“修饰”库/资源/可执行文件名称以避免基于构建配置的冲突（例如，“DEBUG”v. “RELEASE”、“static 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 系统可以链接单线程和多线程将目标线程到单个应用程序中没有问题。鉴于当今多核和多线程的发展，大型企业是否需要建立以下内容来识别“单”与“多线程”编译目标？< /strong>

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

...我们是否错过了任何其他目标冲突，例如使用和不使用 STL 进行编译（在 C++ 上）？

顺便说一句，Microsoft 在以下位置有库命名约定： http://msdn.microsoft.com/en -us/library/aa270400(v=vs.60).aspx 及其 DLL 命名约定位于：http://msdn.microsoft.com/en-us /library/aa270964(v=vs.60).aspx

一年前关于 SO 的类似问题没有讨论线程也没有引用 Microsoft 约定可以可以在以下位置找到：什么是MSVC dll、静态库和导入库的正确命名约定

原文

[ EDIT ] ==>
To clarify, in those environments where multiple targets are deployed to the same directory, Planet Earth has decided on a convention to append "d" or "_d" or "_debug" to the "DEBUG" version (of a library or executable). Such a convention can be considered "ubiquitous" and "understood", although (of course) not everybody does this.

SIMILARLY, to resolve ambiguity between "shared" and "static" versions of a library, a common convention is to append something to distinguish between the static-and-shared (like "myfile.lib" for shared-import-lib-on-Windows and "myfile_s.lib" for static-import-lib-on-Windows). While Posix does not have this ambiguity based on file extension, remember that the file extension is not used on the "link line", so it is similarly useful to be able to explicitly specify the "static" or "shared" version of a library.

For the purpose of this question, both "debug/release" and "static/shared" are promoted to "ubiquitous convention to decorate the file name root".

QUESTION: Does any other deployment configuration get "promoted" to this level of "ubiquitous convention" such that it would become explicit in the file target root name?

My current guess is "no". For the answer to be "Yes", it would require: More than one configuration for given target is intended to be "used" (and thus deployed to a common directory, which is the assumed basis for the question).

In the past, we compiled with-and-without "web plug-in" capability, which similarly required that name decoration, but we no longer build those targets (so I won't assert that as an example). Similarly, we sometimes compile with-and-without multi-byte character support, but I hate that, so I won't assert that either.

[ORIGINAL QUESTION]

We're establishing library naming conventions/policy, to be applied across languages and platforms (e.g., we support hybrid products using several languages on different platforms, including C/C++, C#, Java). A particular goal is to ensure we handle targets/resources for mobile development (which is new to us) in addition to our traditional desktop (and embedded) applications.

Of course, one option is to have different paths for targets from different build configurations. For the purpose of this question, the decision is made to have all targets co-locate to a single directory, and to "decorate" the library/resource/executable name to avoid collisions based on build configuration (e.g., "DEBUG" v. "RELEASE", "static lib" v. "shared/DLL", etc.)

Current decision is similar to others on the web, where we append tokens to avoid naming collisions:

  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)

(The above are Windows examples, but these policies similarly apply to our POSIX systems.)

These are based on:

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

QUESTION: We do not have legacy applications that must be compiled single-threaded, and my understanding is that (unlike Microsoft) POSIX systems can link single- and multi-threaded targets into a single application without issue. Given today's push towards multi-core and multi-threaded, Is there a need in a large enterprise to establish the following to identify "single-" versus "multi-threaded" compiled targets?

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

...and did we miss any other target collision, like compile with-and-without STL (on C++)?

As an aside, Microsoft has library naming conventions at:
http://msdn.microsoft.com/en-us/library/aa270400(v=vs.60).aspx and their DLL naming conventions at: http://msdn.microsoft.com/en-us/library/aa270964(v=vs.60).aspx

A similar question on SO a year ago that didn't talk about threading and didn't reference the Microsoft conventions can be found at: What is proper naming convention for MSVC dlls, static libraries and import libraries

分享到QQ

分享到微博