Question

[ 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

Answer 1

You are using an ancient compiler. There is no need to establish such a standard in an enterprise, the vendor has already done this. Microsoft hasn’t shipped a single-threaded version of the CRT for the past 13 years. Similarly, Windows has been a Unicode operating system for the past 17 years. It makes zero sense to still write Unicode agnostic code these days.

But yes, the common convention is to append a “d” for the debug build of a library. And to give a DLL version of a library a completely different name.