Что такое правильное соглашение об именах для библиотек MSVC, статических библиотек и библиотек импорта

Question

Что такое стандартное или «самое популярное» соглашение об именах для сборки библиотек 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-buidls? Насколько я знаю, обычно именами являются foo.dll и foo.lib, но как вы обычно различаете библиотеку импорта и статическую?

Примечание: Я спрашиваю, потому что CMake создает довольно unpleasant столкновение между ними имен как импорт и статическую библиотеку как foo.lib. См. bug report. Ответ будет помочь мне убедить разработчиков исправить эту ошибку.

Answer 1

Вы различаете библиотеку и DLL-расширение. Но вы различаете библиотеку импорта и статическую библиотеку с именем filename, а не с расширением.

Не будет случая, когда существует библиотека импорта для набора кода, который был создан как статическая библиотека или где существует статическая библиотека для dll. Это две разные вещи.

Существует не одно стандартное соглашение о стандарте для MSVC. Как правило, имя библиотеки, которое заканчивается на «D», часто представляет собой отладочную сборку библиотечного кода, msvcrtd.dll против msvcrt.dll, но кроме этого нет стандартов.

Answer 2

Как уже упоминалось, нет стандартов, но существуют популярные соглашения. Я не уверен, как однозначно судить о том, что является самым популярным соглашением. Кроме того, номенклатура для статических и импортных библиотек, о которых вы просили, также имеет аналогичное различие между именами библиотек выпусков и библиотек отладки, особенно в Windows.

Оба варианта (например, статические и импортные, а также debug vs. release) могут обрабатываться одним из двух способов: разными именами или разными папками. Я обычно предпочитаю использовать разные имена, потому что я чувствую, что это минимизирует вероятность ошибочного использования типа библиотеки позже, особенно после установки или других действий по перемещению файлов.

Обычно я использую foo.dll и foo.lib для общей библиотеки в Windows и foo_static.lib для статической библиотеки, когда я хочу иметь как общие, так и статические версии. Я видел, как другие используют это соглашение, поэтому он может быть «самым популярным».

Поэтому я бы рекомендовал следующее дополнение к Вашему столу:

Windows/MSVC:

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

Тогда в CMake, вы можете либо

add_library(foo_static STATIC foo.cpp) 

или

add_library(FooStatic STATIC foo.cpp) 
set_target_properties(FooStatic PROPERTIES OUTPUT_NAME "foo_static") 

если по какой-то причине вы не хотите использовать «foo_static» в качестве имени символической библиотеки.

Answer 3

Насколько я знаю, нет никакого «стандартного» стандарта, по крайней мере, не будет стандартного большинства программ.

Мое соглашение - назвать мой динамический и статический .lib одинаково, но поместите их в разные каталоги, если проект будет поддерживать как статическую, так и динамическую привязку.Например:

foo-static 
    foo.lib 

foo 
    foo.lib 
    foo.dll 

Библиотека линковать зависит от выбора библиотечных каталогов, так что это почти полностью отделен от остальной части процесса сборки (он не будет отображаться в истоке, если вы используете MSVC-х #pragma comment(lib,"foo.lib") объект, и он не отображается в списке библиотек импорта для компоновщика).

Я видел это довольно много раз. Кроме того, я думаю, что проекты на базе MSVC/Windows, как правило, чаще всего связаны с одним официальным типом связи - либо статическим, , либо динамическим. Но это только мое личное наблюдение.

Вкратце: Windows/MSVC

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

Вы должны быть в состоянии использовать этот каталог на основе шаблона с CMake (никогда не использовал его). Кроме того, я не думаю, что это «ошибка». Это просто отсутствие стандартизации. CMAKE делает (imho) правильную вещь не, чтобы установить псевдостандарт, если всем это нравится по-другому.

Answer 4

Для библиотек нет стандартного соглашения об именах. Традиционные имена библиотек имеют префикс lib. Многие линкеры имеют опции для добавления lib к имени библиотеки в командной строке.

Статические и динамические библиотеки обычно идентифицируются их расширением; хотя это не требуется. Таким образом, libmath.a будет представлять собой статическую библиотеку, тогда как libmath.so или libmath.dll будет динамической библиотекой.

Общим соглашением об именах является добавление категории библиотеки к названию. Например, статическая математическая библиотека отладки будет «libmathd.a» или в Windows, «lib_math_debug». Некоторые магазины также добавляют Unicode в качестве атрибута имени файла.

Если вы хотите, вы можете добавить _msvc к имени библиотеки, чтобы указать, что библиотека требуется или была создана MSVC (чтобы отличить от GCC и других инструментов). Популярным соглашением при работе с несколькими платформами является размещение объектов и библиотек в конкретных папках платформы. Например, папка ./linux/ будет содержать объекты и библиотеки для Linux и аналогично ./msw/ для платформы Microsoft Windows.

Это проблема стиля. Вопросы стиля часто рассматриваются как религиозные проблемы: ни одна из них не является неправильной, нет универсального стиля, и они являются индивидуальным предпочтением. Что бы вы ни выбрали, просто будьте последовательны.

Answer 5

Как уже сообщалось, нет единственного стандарта для именования файлов в окнах.

Для нашей полной базы продуктов, которая охватывает 100-е из exes, dlls и static libs, мы успешно использовали это в течение многих лет, и это сэкономило много путаницы. В основном это сочетание нескольких методов, которые я видел на протяжении многих лет.

Вкратце все наши файлы как префикса, так и суффикса (не включая само расширение). Все они начинаются с «om» (на основе названия нашей компании), а затем имеют комбинацию из 1 или 2 символов, которая примерно определяет область кода.

Суффикс объясняет, какой тип встроенного файла они содержат и включает до трех букв, используемых в комбинации, в зависимости от сборки, которая включает в себя Unicode, Static, Debug (сборки Dll по умолчанию и не имеют явного идентификатора суффикса). Когда мы запустили эту систему, Unicode не был настолько распространен, и нам пришлось поддерживать как Unicode, так и Unicode-сборки (до Windows 2000 os), теперь все исключительно построено в Юникоде, но мы по-прежнему используем одну и ту же номенклатуру.

Так типичный .lib «набор» файлов может выглядеть

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

Все файлы встроенной в общую папку BIN, которая устраняет много проблем длл-ад для разработчиков, а также делает упростить настройку параметров компилятора/компоновщика - все они указывают на одно и то же местоположение с использованием относительных путей, и никогда не требуется ручное (или автоматическое) копирование библиотек, необходимых для проекта. Наличие этих суффиксов также устраняет любую путаницу в отношении того, какой тип файла у вас может быть, и гарантирует, что у вас не может быть смешанного сценария, в котором вы удаляете отладочную DLL в наборе релизов или наоборот. Все exes также используют аналогичный суффикс (Unicode/Debug) и встраиваются в ту же папку bin.

Существует также одна отдельная папка «включить», каждая библиотека имеет один заголовочный файл в папке include, которая соответствует имени библиотеки/dll (например, omfthread.h). Этот файл сам включает в себя все другие элементы, которые выставлены этой библиотекой. Это упрощает работу, если вы хотите функциональность, находящуюся в foo.dll, вы просто #include "foo.h"; наши библиотеки сильно сегментированы по функциональным возможностям - фактически у нас нет никаких DLL «швейцарских армейских ножей», так что в целом функциональность библиотек имеет смысл. (Каждый из этих заголовков также включает в себя другие предварительные заголовки, будь то наши внутренние библиотеки или другие SDK поставщиков).

Каждый из этих файлов включает внутренние макросы, которые используют # pramga для добавления соответствующего имени библиотеки в линию компоновщика, поэтому отдельные проекты не нужно беспокоиться об этом. Большинство наших библиотек могут быть построены статически или как DLL, а #define OM_LINK_STATIC (если определено) используется для определения того, что хочет сделать отдельный проект (обычно мы используем библиотеки DLL, но в некоторых случаях встроенные в него файлы .exe make больше смысла для развертывания или по другим причинам)

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

Этих макросов (OMLIBNAMESTATIC & OMLIBNAME) использует _DEBUG определить, какой тип телосложения это и генерировать правильное имя библиотеки, чтобы добавить к строке компоновщика.

Мы используем общее определение в статических & DLL-версиях библиотеки для управления надлежащим экспортом класса/функций в сборках dll. Каждый класс или функция экспортируется из библиотеки украшена этот макрос (имя которого совпадает с именем базы для библиотеки, хотя это в значительной степени неважная)

class OMUTHREAD_DECLARE CThread : public CThreadBase 

В версии DLL настроек проекта мы определяем OMFTHREAD_DECLARE = __ declspec (dllexport), в статической библиотечной версии библиотеки мы определяем OMFTHREAD_DECLARE как пустой.

В библиотеках заголовка файла мы определим его на основе того, как клиент пытается связать с ней

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

Типичный проект, который хочет использовать один из наших внутренних библиотек просто добавить соответствующий включать в свои stdafx.h (обычно), и он просто работает, если им нужно связать статическую версию, они просто добавляют OM_LINK_STATIC в свои настройки компилятора (или определяют его в stdafx.h), и он снова работает.

Answer 6

Насколько я знаю, до сих пор нет никаких соглашений относительно этого. Вот пример того, как я это делаю:

{Проект} {подмодуль} {Платформа} {Архитектура} {CompilerRuntime} _ {BuildType} .lib/длл

Полное имя файла должно быть в нижнем регистре только и должны содержать только буквенно-цифровые символы с заранее обозначенными символами подчеркивания. Поле подмодуля, включая его верхнее подчеркивание, является необязательным.

Проект: содержит название/идентификатор проекта. Предпочтительно как можно короче. т.е. «dna»

SubModule: опционально. содержит имя модуля. Предпочтительно как можно короче. т.е. «dna_audio»

Платформа: идентифицирует платформу, с которой компилируется бинарник. т.е. «win32» (Windows), «winrt», «xbox», «android».

Архитектура: описывает архитектуру, с которой скомпилирован бинарный файл. т.е. «x86», «x64», «рука». Там, где имена архитектуры равны для разных битов, используйте свое имя, за которым следует битность. то есть. «name16», «name32», «name64»

CompilerRuntime: необязательно. Не все двоичные файлы ссылаются на время выполнения компилятора, но если они это делают, оно включено сюда. т.е. «vc90» (Visual Studio 2008), «gcc». Где применимо квартира может быть включена, т.е. "vc90mt"

BuildType: необязательно. Это может содержать буквы (в любом порядке), каждый из которых сообщает что-то о специфике сборки. d = отладки (опущено, если выпуск) т = статический (опущено, если динамический) а = ANSI (опущено, если Юникод)

Примеров (предполагая, что проект под названием "ДНК"): dna_win32_x86_vc90.lib/DLL dna_win32_x64_vc90_d.lib/длл dna_win32_x86_vc90_sd.lib dna_audio_win32_x64_vc90.lib/длл dna_audio_winrt_x64_vc110.lib/длл